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Executive  Summary 


Requ irements- Arch itectu re  Mismatch 

The  study  of  the  principles  and  practices  needed  to  produce  a  high-quality  software  architecture 
constitutes  a  rich  and  productive  field  of  investigation,  pursued  vigorously  by  the  Software 
Engineering  Institute  (SEI)  and  others.  However,  that  field  has  almost  completely  overlooked  an 
inconvenient  truth: 

There  is  a  deep  and  fundamental  mismatch  between  the  information  that 
requirements  specifications  contain  and  the  information  that  architects  need. 

This  mismatch  manifests  in  two  ways: 

1 .  Most  of  what  is  in  a  requirements  specification  does  not  determine  or  “shape”  an 
architecture.  Architectures  are  mostly  driven  or  shaped  by  quality  attribute  requirements. 
These  determine  and  constrain  the  most  important  architectural  decisions.  And  yet  the  vast 
bulk  of  most  requirements  specifications  is  focused  on  the  required  features  and  functionality 
of  a  system,  which  shape  the  architecture  the  least.  Worse,  most  do  a  poor  job  of  specifying 
quality  attributes;  many  ignore  them  altogether. 

2.  Much  of  what  is  useful  to  an  architect  is  not  in  even  the  best  requirement  specification. 

Many  concerns  that  drive  an  architecture  do  not  manifest  as  observables  in  the  system  being 
specified  and  so  do  not  appear  in  requirements  specifications.  These  often  derive  from 
business  goals  in  the  development  organization  itself,  such  as  keeping  people  productively 
employed,  amortizing  investments  in  existing  tools  and  technologies,  satisfying  human 
resource  concerns,  improving  the  organization’s  market  position  relative  to  its  competition, 
and  others. 

Business  Goals  Beget  Quality  Attributes 

We  take  as  an  axiom  that  every  quality  attribute — such  as  user- visible  response  time  or  platform 
flexibility  or  ironclad  security  or  any  of  a  dozen  other  necessities — originates  from  some  higher 
purpose  that  can  be  described  in  terms  of  added  value. 

This  relationship  between  corporate  goals  and  project  goals  seems  self-evident,  but  it  is 
apparently  not  well  understood  in  the  business  literature. 

Purpose 

Our  purpose  is  to  facilitate  better  elicitation  of  high-pedigree  quality  attribute  requirements. 
Toward  this  end,  we  want  to  be  able  to  elicit  business  goals  reliably  and  understand  how  those 
business  goals  influence  quality  attribute  requirements  and  architectures. 

The  elicitation  approaches  outlined  in  this  report  can  be  used  by  requirements  engineers  who  want 
to  produce  a  set  of  requirements  helpful  to  the  software  architect;  by  parties  such  as  those  running 
an  SEI  Quality  Attribute  Workshop  [Barbacci  2003];  or  by  the  architect  when  nobody  else  has 
produced  such  requirements. 
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Classification  of  Business  Goals 


Based  on  an  extensive  literature  survey,  we  were  able  to  produce  a  classification  for  a  large 
number  of  common  business  goals.  The  classification  categories  are 

•  Maintaining  growth  and  continuity  of  the  business 

•  Meeting  the  company’s  financial  objectives 

•  Meeting  personal  objectives 

•  Meeting  responsibility  to  employees 

•  Meeting  responsibility  to  society 

•  Meeting  responsibility  to  country 

•  Meeting  responsibility  to  shareholders 

•  Managing  market  position 

•  Improving  business  processes 

•  Managing  quality  and  reputation  of  products 

Managing  Change 

Within  these  categories,  the  literature  also  makes  clear  that  changes  in  the  environment  must  also 
be  managed.  The  categories  of  the  environment  that  the  literature  identified  as  important  to 
manage  are  the  social  environment,  legal  and  regulatory  environment,  competitive  environment 
and  technological  change,  and  customer  environment. 

Business  Goal  Scenarios 

The  purpose  of  business  goal  scenarios  is  to  ensure  that  all  business  goals  are  expressed  clearly,  in 
a  consistent  fashion,  and  contain  sufficient  information  to  enable  their  processing  through  the 
further  steps  of  our  technique. 

A  business  goal  scenario  has  six  parts: 

1.  Goal-subject.  This  is  the  stakeholder  that  owns  the  goal.  The  stakeholder  may  be  an 
individual,  an  individual  in  an  identified  organization  if  more  than  one  organization  is  in 
play,  or  (in  the  case  of  a  goal  that  has  no  one  owner  and  has  been  assimilated  into  an 
organization)  the  organization  itself. 

2.  Goal-object.  This  is  the  entity  to  which  the  goal  applies  or  that  will  benefit  from  the  goal’s 
achievement.  A  goal-object  will  typically  be  one  of  the  set  from  the  first  column  of  Table  2: 
individual,  system,  portfolio,  and  so  on. 

3.  Environment.  This  is  the  context  for  this  goal.  It  acts  as  a  rationale  for  the  goal.  One 
source  for  this  entry  is  found  in  the  five  different  environmental  factors  of  Osterwalder  and 
Pigneur:  social,  legal,  competitive,  customer,  and  technological  [Osterwalder  2004]. 

4.  Goal.  This  is  an  element  from  Table  1,  or  any  business  goal  (whether  in  the  table  or  not) 
that  can  be  articulated  by  the  person  being  interviewed. 

5.  Goal-measure.  This  is  a  measurement  to  determine  whether  the  goal  has  been  achieved. 
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6.  Pedigree  and  value.  This  tells  us  the  degree  of  confidence  in  the  goal,  the  goal’s  volatility, 
and  the  value  of  achieving  the  goal. 

Pedigreed  Attribute  eLicitation  Method  (PALM) 

First,  we  want  to  empower  architects  to  spot  the  likelihood  of  missing  requirements  by  giving 
them  a  clear  and  full  picture  of  the  operative  business  goals.  Second,  we  want  to  empower 
architects  to  be  able  to  question  difficult  requirements  that  may  not  be  necessary  because  they  do 
not  support  any  important  business  goal. 

Toward  these  two  ends,  we  have  developed  a  method  called  the  Pedigreed  Attribute  eLicitation 
Method  (PALM)  and  have  tried  it  out  in  a  real-world  setting. 

The  steps  of  PALM,  which  can  be  carried  out  in  a  two-day  exercise,  are  as  follows.  For  each  step 
a  nominal  duration  is  given. 

1.  PALM  overview  presentation:  overview  of  PALM,  the  problem  it  solves,  its  steps,  its 
expected  outcomes.  (30  minutes) 

2.  Business  drivers  presentation:  discussion  of  business  drivers  by  project  management. 

What  are  the  goals  of  the  customer  organization  for  this  system?  What  are  the  goals  of  the 
development  organization?  (60  minutes) 

3.  Architecture  drivers  presentation:  briefing  by  the  architect  on  the  driving  (shaping) 
business  and  quality  attribute  requirements.  (30  minutes) 

4.  Business  goals  elicitation  exercise:  Using  the  standard  business  goal  categories  of  Table  1 
to  guide  discussion,  we  capture  the  set  of  important  business  goals  for  this  system.  Business 
goals  are  elaborated  and  prioritized,  and  expressed  as  business  goal  scenarios.  (2  hours) 

5.  Identifying  potential  quality  attributes  from  business  goals:  For  each  important  business 
goal  scenario,  participants  describe  a  quality  attribute  that  (if  architected  into  the  system) 
would  help  achieve  it.  (2.5  hours.) 

6.  Assignment  of  pedigree  to  existing  quality  attribute  drivers:  For  each  architectural 
driver  named  in  Step  3,  we  identify  which  business  goal(s)  it  is  there  to  support.  If  it  supports 
none,  or  if  any  supported  business  goal  has  a  questionable  pedigree  such  as  low  value  or  high 
volatility,  that  is  recorded  as  a  risk.  Otherwise,  it  is  recorded  as  a  non-risk.  (2.5  hours) 

7.  Exercise  conclusion:  review  of  results,  next  steps,  and  participant  feedback.  (30  minutes) 

Validating  the  Method 

We  held  a  workshop  in  Pittsburgh  and  one  in  Amsterdam  in  April  2009  to  help  us  validate  the 
approach  laid  out  in  this  report.  We  invited  a  number  of  architecture  experts  to  the  workshops  in 
each  venue:  people  whose  experience  in  developing  architectures  based  on  quality  attribute 
requirements  runs  long  and  deep.  At  these  workshops,  we  presented  the  elicitation  approach  and 
took  comments,  criticisms,  and  ideas  for  improvement.  We  also  conducted  a  mock  elicitation 
exercise  at  each  workshop  to  gain  preliminary  experience  with  the  practicalities  of  using  PALM 
with  live  subjects.  Both  workshops  validated  for  us  the  strong  link  between  business  goals  and 
quality  attribute  requirements.  The  participants  gave  us  strong  encouragement  as  to  the 
usefulness  of  establishing  a  business-goal-based  pedigree  for  quality  attribute  requirements  early 
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in  the  life  cycle,  and  they  told  us  how  a  method  such  as  PALM  could  be  used  to  support  Request 
for  Proposal  (RFP)  activities  as  well  as  activities  to  respond  to  an  RFP. 

Piloting  the  Method 

We  piloted  PALM  in  a  day-and-a-half  engagement  with  Boeing  Air  Traffic  Management  on 
August  30  and  Sept  1,  2009.  We  conducted  the  pilot  as  an  interview  with  the  project  manager  and 
the  project  architect.  The  pilot  produced  value  for  Boeing,  uncovering  a  number  of  business  goals 
that  had  previously  not  been  known,  or  at  best  had  only  been  implicit  in  the  minds  of  the 
participants.  After  the  pilot,  the  architect  presented  the  results  of  the  pilot  to  his  management 
team,  and  the  project  manager  shared  the  results  with  the  project  team. 
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Abstract 


The  primary  purpose  of  the  architecture  for  a  software -reliant  system  is  to  satisfy  the  driving 
behavioral  and  quality  attribute  requirements.  Quality  attribute  requirements  tend  to  be  poorly 
captured  and  poorly  represented  in  requirements  specifications,  which  focus  on  functionality.  It  is 
often  up  to  the  architect’s  own  initiative  to  capture  the  actual  quality  attribute  requirements  for  a 
system  under  development.  Quality  attributes  come  about  because  of  the  business  goals  behind 
the  system  being  developed.  Business  goals  drive  the  conception,  creation,  and  evolution  of 
software-reliant  systems.  This  report  examines  business  goals  from  the  point  of  view  of  the 
software  architect.  It  presents  a  wide  survey  of  business  goal  categories  from  the  business 
literature  and  uses  that  survey  to  produce  a  classification  of  business  goals.  It  introduces  the 
concept  of  goal-subject  (the  person  or  entity  who  owns  the  business  goal)  and  goal-object  (the 
person  or  entity  that  the  goal  is  intended  to  benefit).  Those  concepts  are  essential  to  the  structure 
of  a  business  goal  scenario — a  systematic  way  to  elicit  and  express  business  goals.  Using  the 
concept  of  a  business  goal  scenario  drives  the  Pedigreed  Attribute  elicitation  Method  (PALM), 
developed  by  the  authors  for  eliciting  architecturally  significant  business  goals.  The  report 
illustrates  how  to  use  architecturally  significant  business  goals  to  produce  a  set  of  derived  quality 
attribute  requirements  that  can  then  be  vetted  and  elaborated  with  the  appropriate  goal-subject(s) 
and  goal-object(s).  This  approach  has  been  vetted  in  two  workshops  and  the  method  piloted  in  an 
industrial  setting. 
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1  Introduction 


1.1  The  Requirements/ Architecture  Mismatch 

The  study  of  the  principles  and  practices  needed  to  produce  a  high-quality  architecture  constitutes 
a  rich  and  productive  field  of  investigation,  pursued  vigorously  by  the  Carnegie  Mellon®  Software 
Engineering  Institute  (SEI)  and  others.  However,  that  field  has  almost  completely  overlooked  an 
inconvenient  truth: 

There  is  a  fundamental  mismatch  between  the  information  that  requirements 
specifications  contain  and  the  information  that  architects  need. 

This  mismatch  manifests  in  two  ways: 

1 .  Most  of  what  is  in  a  requirements  specification  does  not  affect  the  architecture. 

Architectures  are  mostly  driven  or  “shaped”  by  quality  attribute  requirements.  These 
determine  and  constrain  the  most  important  architectural  decisions.  And  yet  the  vast  bulk  of 
most  requirements  specifications  is  focused  on  the  required  features  and  functionality  of  a 
system,  which  shape  the  architecture  the  least.  Worse,  most  do  a  poor  job  of  specifying 
quality  attributes;  many  ignore  them  altogether. 

2.  Much  of  what  is  useful  to  an  architect  is  not  in  even  the  best  requirement  specification. 

Many  concerns  that  drive  an  architecture  do  not  manifest  as  observables  in  the  system  being 
specified  and  so  do  not  appear  in  requirements  specifications.  These  often  derive  from 
business  goals  in  the  development  organization  itself,  such  as  keeping  people  productively 
employed,  amortizing  investments  in  existing  tools  and  technologies,  satisfying  human 
resource  concerns,  improving  the  organization’s  market  position  relative  to  its  competition, 
and  others.  This  relation  between  business  goals  and  the  architecture  has  been  identified  by 
others  as  well  as  the  authors  of  this  report.  See,  for  example  works  by  Gross,  Velasquez,  and 
Sangwan  [Gross  2000,  Velasquez  2006,  Sangwan  2007]. 

1 .2  Business  Goals  Beget  Quality  Attributes 

Every  quality  attribute — such  as  user-visible  response  time  or  platform  flexibility  or  ironclad 
security  or  any  of  a  dozen  other  needs — should  originate  from  some  higher  purpose  that  can  be 
described  in  terms  of  added  value. 

If  we  ask,  for  example,  “Why  do  you  want  this  system  to  have  a  really  fast  response  time?”  we 
might  hear  that  this  will  differentiate  the  product  from  its  competition  and  let  the  developing 
organization  capture  market  share;  or  that  this  will  make  the  soldier  a  more  effective  warfighter, 
which  is  the  mission  of  the  acquiring  organization;  or  other  reasons  having  to  do  with  the 
satisfaction  of  some  business  goal. 

This  relationship  between  corporate  goals  and  project  goals  seems  self-evident,  but  is  apparently 
not  well  understood  in  the  business  literature.  Indeed,  “there  is  a  dearth  of  writing  about  how 
corporate  strategy  gets  translated  into  implementation,  particularly  at  the  program  or  project 
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level”  [Morris  2005],  Instead,  “much  of  traditional  management  writing  tends  only  to  cover  the 
strategic  management  processes  that  formulate  and  implement  strategy  at  the  corporate  level.”  In 
writing  about  this  relationship,  Morris  and  Jamieson  produce  a  picture  (Figure  1)  that  conveys 
approximately  the  idea  we  describe.1 


Figure  1:  Corporate  Goals  Should  Drive  Project  Goals  [Morris  2005] 

Whereas  quality  attributes  should  flow  from  business  goals,  not  all  business  goals  lead  to  quality 
attributes.  For  example,  the  goal  to  reduce  costs  may  be  satisfied  by  lowering  the  facility’s 
thermostats  in  the  winter  or  reducing  employees’  pensions. 

Still  other  business  goals  may  directly  affect  the  architecture  without  precipitating  a  quality 
attribute  requirement  per  se.  For  example,  a  software  architect  related  to  us  that  some  years  ago 
he  delivered  an  early  draft  of  the  architecture  to  his  manager.  The  manager  remarked  that  a 
database  was  missing  from  the  architecture.  The  architect,  pleased  that  the  manager  had  noticed, 
explained  how  he  had  devised  a  design  approach  that  obviated  the  need  for  a  bulky,  expensive 
database.  The  manager,  however,  pressed  for  the  design  to  include  a  database  because  the 
organization  had  a  database  unit  employing  a  number  of  highly  paid  technical  staff  that  currently 
were  unassigned  and  needed  work.  No  requirements  specification  would  capture  such  a 
requirement,  nor  would  any  manager  allow  such  a  motivation  to  be  captured.  And  yet  that 
architecture,  had  it  been  delivered  without  a  database,  would  have  been  just  as  deficient  from  the 
point  of  view  of  the  manager  as  if  it  had  failed  to  deliver  an  important  functionality  or  quality 
attribute. 

Figure  2  illustrates  the  major  points  above.  In  the  figure,  the  arrows  mean  “leads  to.”  The  solid 
arrows  highlight  the  relationships  of  most  interest  to  us. 


Their  paper  contains  an  excellent  summary  of  the  literature,  such  as  it  is,  linking  corporate  and  project  goals. 
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Figure  2:  Some  Business  Goals  May  Lead  to  Quality  Attribute  Requirements  (Which  Lead  to 

Architectures),  or  Lead  Directly  to  Architectural  Decisions,  or  Lead  to  Non-Architectural 
Solutions. 


1.3  Terminology 

Throughout  this  report  we  will  primarily  use  the  term  business  goal  to  refer  to  an  objective  or 
target  to  be  achieved  by  a  business  [American  Heritage  2010].  The  most  routine  case  is  when  a 
stakeholder  for  an  organization  wants  that  same  organization  to  achieve  something  of  value. 

In  the  U.S.  Department  of  Defense  (DoD),  two  related  terms  arise  and  should  be  reconciled. 

1 .  A  mission  goal  (sometimes  mission  driver )  is  an  expression  of  a  goal  concerning  the 
achievement  of  some  mission,  usually  military  and  operational  in  nature. 

2.  An  acquisition  goal  (sometimes  acquisition  driver)  is  a  goal  of  an  acquisition  organization  to 
meet  certain  objectives,  usually  related  to  cost  and  schedule  or  contractual  matters, 
acquisition  organizations  also  have  goals  to  acquire  systems  that  help  warfighters  achieve 
their  mission  goals. 

Mission  goals  are  often  expressed  in  terms  of  key  performance  parameters  such  as 
“interoperability.”  These  can  be  elaborated  and  refined  into  key  system  attributes  that  the  system 
must  exhibit  in  order  to  be  acceptable. 

For  the  purposes  of  this  report,  all  of  these  terms  are  synonymous.  For  example,  an  acquisition 
goal  can  be  seen  as  a  business  goal  of  an  acquisition  organization.  A  mission  goal  can  be  seen  as 
the  business  goal  of  a  warfighting  organization.  A  DoD  contracting  organization  will  have  to 
build  systems  that  serve  both  DoD  mission  goals  and  its  own  business  goals.  The  DoD  has  already 
adopted  the  business  paradigm  for  its  warfighting  capability  when,  for  example,  the  Army  speaks 
of  building  an  enterprise  architecture  to  let  a  warfighter  access  networks  from  anywhere  in  the 
world  [Bergey  2009]. 

1.4  Purpose 

Our  purpose  is  to  facilitate  better  capture  and  expression  of  high-pedigree,  architecturally 
significant  requirements.  “Architecturally  significant  requirements  are  those  requirements  that 
play  an  important  role  in  determining  the  architecture  of  the  system  . .  .e.g.,  the  system  must 
record  every  modification  to  customer  records  for  audit  purposes.  The  system  must  respond 
within  five  seconds”  [EPF  2010].  A  major  source  of  architecturally  significant  requirements  is  the 
set  of  business  goals  that  led  to  the  system’s  being  developed.  Therefore,  we  want  to  be  able  to 
elicit  business  goals  reliably  and  understand  how  those  business  goals  influence  quality  attribute 
requirements  and  architectures. 
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The  elicitation  approaches  outlined  in  this  report  can  be  used  by  requirements  engineers  who  want 

to  produce  a  set  of  requirements  helpful  to  the  software  architect;  by  parties  such  as  those  running 

SEI  Quality  Attribute  Workshops  [Barbacci  2003];  or  by  the  architect  in  cases  where  nobody  else 

produced  such  requirements. 

After  reading  this  report,  any  of  these  parties  should  be  able  to 

1 .  use  a  candidate  set  of  business  goals  to  help  elicit  the  business  goals  that  are  driving  the 
project  at  hand 

2.  produce  a  set  of  quality  attribute  requirements  that  could  reasonably  be  expected  to  apply  to 
the  project  at  hand,  given  the  operative  business  goals.  This  expected  set  can  then  be 
compared  to  the  existing  set;  a  mismatch  gives  the  architect  a  reason  to  probe  deeper  into  the 
requirements. 

1 .5  Organization  of  this  report 

The  outline  of  this  report  is  as  follows: 

•  Section  2,  “Classifying  Business  Goals,”  synthesizes  our  own  categorization  of  business  goals 
based  on  the  categories  identified  in  the  Appendix.  It  also  introduces  the  notions  of  goal- 
subject  (the  entity  having  the  goal)  and  goal-object  (the  entity  to  which  the  goal  applies). 

•  Section  3,  “Expressing  Business  Goals  introduces  the  business  goal  scenario,  a  mechanism 
for  capturing  and  expressing  business  goals  in  a  consistent  and  useful  manner. 

•  Section  4,  “From  Business  Goals  to  Quality  Attributes,”  shows  how  to  use  business  goal 
scenarios  in  a  multi-step  technique  for  eliciting  and  capturing  business  goals  that  will  have 
architectural  impact  and  also  for  deriving  the  resulting  quality  attribute  requirements.  It 
describes  how  we  have  validated  and  piloted  the  approach  in  an  industrial  setting. 

•  Section  5  summarizes  and  discusses  how  our  work  may  be  incorporated  into  the  body  of  SEI 
architecture-centric  engineering  practices. 

•  The  Appendix  summarizes  an  extensive  literature  search  to  present  categories  of  business 
goals  used  by  other  authors. 
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2  Classifying  Business  Goals 


This  section  summarizes  the  literature  survey  presented  in  the  Appendix  to  produce  a  systematic 
way  to  classify  business  goals  that  we  will  use  to  guide  their  elicitation. 

2.1  Eschewing  a  Taxonomy 

First,  we  dispense  with  the  notion  of  a  business  goal  taxonomy.  A  taxonomy  must  exhibit  mutual 
exclusivity;  that  is,  a  subject  must  belong  to  one  taxon  and  one  taxon  only  [Makinen  2007]. 

None  of  the  classification  schemes  we  present  in  the  Appendix  are  taxonomies;  they  all  fail  the 
mutual  exclusivity  test.  An  extensive  search  of  the  business  literature  has  revealed  no  existing 
taxonomy  of  organizational  business  goals. 

Happily,  we  do  not  need  a  taxonomy.  Our  goal  is  to  provide  a  classification  that  will  help  us  ask 
the  right  questions  about  an  organization’s  reasons  for  developing  or  acquiring  a  software -reliant 
system.  Each  category  should  prompt  questions  about  the  existence  of  organizational  business 
goals  that  fall  into  that  category.  If  the  categories  overlap,  then  this  might  cause  us  to  ask 
redundant  questions.  This  is  not  harmful  and  is  probably  helpful — redundancy  being  a  well- 
known  tactic  for  achieving  reliability. 

2.2  Synthesis  of  Business  Goal  Categories 

Many  of  the  works  summarized  in  the  Appendix  offer  their  own  sets  of  business  goals.  By 
performing  an  affinity  exercise  among  all  of  the  goals  mentioned,  we  have  created  the  following 
set  of  business  goal  categories  that  synthesize  all  of  the  previous  results: 

•  Maintaining  growth  and  continuity  of  the  organization 

•  Meeting  financial  objectives 

•  Meeting  personal  objectives 

•  Meeting  responsibility  to  employees 

•  Meeting  responsibility  to  society 

•  Meeting  responsibility  to  country 

•  Meeting  responsibility  to  shareholders 

•  Managing  market  position 

•  Improving  business  processes 

•  Managing  quality  and  reputation  of  products 

Table  1  shows  the  business  goals  cited  in  the  Appendix  that  contribute  to  each  category.  We  can 
use  these  categories  to  facilitate  business  goal  elicitation,  to  help  stimulate  stakeholders’  thinking, 
and  to  help  gauge  the  coverage  and  completeness  of  an  elicited  set. 
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Table  1:  Synthesized  Business  Goal  Categories 


Category 

Hofstede  et  al.: 

“Hofstede  goals” 

Usunieret  al.:  Ethical  (E) 

or  Self-Interest  (SI)* 

Fulmer:  Business 

Goals  for  CEOs 

Porter:  Marketing 

Strategies 

Kazman  and  Bass: 

Business  Goals 

Collected  from 

ATAM  Exercises 

Osterwalder  and 

Pigneur:  An  Ontology 

for  Business  Models 

de  Reuver,  Bouwman, 

and  Maclnnes:  What 

Drives  Business  Models 

Maintaining 
growth  and 
continuity  of  the 
organization 

Growth  of  the  business 

SI* 

Maximize  the  company's  rate 
of  growth 

Increase  sales  growth 

Continuity  of  the  business 

SI 

Survival 

Run  a  stable  organization 

Meeting 

financial 

objectives 

This  year's  profits 

SI* 

Maximize  profits  over  the  short 
run 

Manage  financial 
aspects  (revenue 
flows,  etc.) 

Profits  10  years  from  now 

SI 

Maximize  profit  over  the  long 
run 

SI 

Achieve  business  goals 
through  financial  objectives 

Maximize  the  company’s  net 
assets  and  reserves 

Keep  tax  payments  to  a 
minimum 

Meeting 

personal 

objectives 

Personal  wealth 

Power 

SI* 

Honor,  face,  reputation 

SI 

Game  and  gambling  spirit 

Family  interests 
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Category 

Hofstede  et  al.: 

“Hofstede  goals” 

Usunieret  al.:  Ethical  (E) 

or  Self-Interest  (SI)* 

Fulmer:  Business 

Goals  for  CEOs 

Porter:  Marketing 

Strategies 

Kazman  and  Bass: 

Business  Goals 

Collected  from 

ATAM  Exercises 

Osterwalder  and 

Pigneur:  An  Ontology 

for  Business  Models 

de  Reuver,  Bouwman, 

and  Maclnnes:  What 

Drives  Business  Models 

Creating  something  new 

Be  the  leading  innovator  in  the 
industry 

Meeting 
responsibility 
to  employees 

Responsibility  toward 
employees 

E* 

Provide  high  rewards  and 
benefits  to  employees 

Create  a  pleasant  and  friendly 
workplace 

Have  satisfied  employees 

Meeting 
responsibility 
to  society 

Respecting  ethical  norms 

Responsibility  toward 
society 

E* 

Run  an  ethical  organization 

Be  a  socially  responsible 
company 

Be  of  service  to  the  community 

Social 

environment 

Operate  effectively 
within  social 
environment 

Staying  within  the  law 

E* 

Legal 

environment 

Regulatory  drivers 

Operate  effectively 
within  legal 
environment 

Meeting 
responsibility 
to  country 

Patriotism,  national  pride 

E 
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Category 

Hofstede  et  al.: 

“Hofstede  goals” 

Usunieret  al.:  Ethical  (E) 

or  Self-Interest  (SI)* 

Fulmer:  Business 

Goals  for  CEOs 

Porter:  Marketing 

Strategies 

Kazman  and  Bass: 

Business  Goals 

Collected  from 

ATAM  Exercises 

Osterwalder  and 

Pigneur:  An  Ontology 

for  Business  Models 

de  Reuver,  Bouwman, 

and  Maclnnes:  What 

Drives  Business  Models 

Meeting 
responsibility 
to  shareholders 

Maximize  dividends  for  the 
shareholders 

Managing 

market 

position 

SI 

Be  a  market  leader  in  your 
respective  market(s) 

Maximize  the  market  share 

Focusing  (on  a  specific 
niche) 

Improve  market  position 

Competitive 

forces 

Customer 

demand 

Market  drivers 

Operate  effectively 
within  competitive 
environment 

Improving 

Business 

Processes 

SI 

Replacement  of  labor  by 
automation 

Diversification  of  operational 
sequence 

Elimination  of  intermediate 
stages 

Automatic  tracking  of 
business  events 

Collection,  communication, 
and  retrieval  of  operational 
knowledge 

Improvement  of  decision 
making 

Coordination  across  distance 

Alignment  between  task  and 
process 

Management  on  basis  of 
process  measurements 

Support  improved 
business  processes 

Manage  customer 
relationship 

Manage 

infrastructure 
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Category 

Hofstede  et  at: 

“Hofstede  goals” 

Usunier  et  at:  Ethical  (E) 

or  Self-Interest  (SI)* 

Fulmer:  Business 

Goals  for  CEOs 

Porter:  Marketing 

Strategies 

Kazman  and  Bass: 

Business  Goals 

Collected  from 

ATAM  Exercises 

Osterwalder  and 

Pigneur:  An  Ontology 

for  Business  Models 

de  Reuver,  Bouwman, 

and  Maclnnes:  What 

Drives  Business  Models 

Managing 

SI 

Provide  the  best  quality 

Differentiation 

Improve  capability/quality 

Operate  effectively 

quality  and 

products  and  services  possible 

Cost  leadership 

of  system 

within  customer 

reputation  of 

Improve  confidence  in 

environment 

products2 

and  perception  of  the 

Operate  effectively 

system 

within  technological 

Reduce  total  cost  of 

environment 

ownership 

*  Entries  marked  with  an  asterisk  were  identified  explicitly  as  either  ethical  or  self-interest  goals  by  Usunier  and  colleagues. 
Entries  not  marked  with  an  asterisk  were  assigned  to  categories  by  the  authors. 


A  more  generous  name  for  this  category  might  be  “Meeting  responsibility  to  customers.” 
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Literature  included  in  the  survey  in  the  Appendix  that  is  missing  from  Table  1  is  listed  below: 

•  Mitchell  and  Coles:  Seven  Key  Elements  of  a  Business  Model  (who,  what,  when,  etc.) 
[Mitchell  2003] 

•  Mitchell,  Agle,  and  Wood:  Stakeholder  Theory  or  “The  Principle  of  Who  or  What  Really 
Counts”  [Mitchell  1997] 

•  McIntosh  and  Nelson:  Changing  business  models  can  define  an  industry  [McIntosh  2007] 

•  The  Open  Group  Architecture  Framework  (TOGAF)  [TOGAF  2009] 

We  will  make  use  of  these  contributions  shortly. 

2.3  The  Goal-Subject  of  Business  Goals 

Here  we  introduce  the  concept  of  a  goal’s  subject — that  is,  the  person  who  has  the  goal.  If  the 
business  goal  is,  for  example,  “maximize  dividends  for  the  shareholders,”3  who  is  it  that  cares 
about  that?  It  is  probably  not  the  programmers  or  the  system’s  end  users  (unless  they  happen  to 
own  stock). 

Mitchell,  Agle,  and  Wood’s  Stakeholder  Theory  suggests  candidate  goal-subject(s)  of  a  business 
goal  and  identifies  people  who  might  have  business  goals  to  contribute  [Mitchell  1997].  In 
executing  PAFM,  we  will  seek  stakeholders  with  high  “salience”  from  whom  to  elicit  business 
goals,  and  record  those  stakeholders  as  the  goal-subjects. 

Many  authors  write  about  the  importance  of  aligning  strategies  and  goals  throughout  an 
organization.  Morris  and  Jamieson’s  “Moving  from  Corporate  Strategy  to  Project  Strategy” 
[Morris  2005]  is  an  exemplar.  Partington  identifies  three  levels  of  strategy  (corporate,  business, 
and  operational)  that  should  be  aligned  with  each  other  [Partington  2000];  see  Figure  3. 


Three  different  levels  of  strategy  are  commonly  distinguished: 

1 .  At  the  corporate  level,  strategy  is  concerned  with  what  businesses  the  company  as  a 
whole  should  be  in,  and  with  justifying  why — in  terms  of  added  value — those  business 
units  should  be  grouped  together  corporately. 

2.  At  the  business  level,  strategy  involves  determining  what  markets  a  business  unit  is 
competing  in,  how  it  should  compete,  where  it  wants  to  go  and  how  it  should  get  there. 
The  answer  to  the  last  question  will  result  in  the  creation  of  programmes  of  projects  to 
enable  business  units  to  achieve  their  strategies. 

3.  Operational  level  strategies  focus  on  the  role  of  individual  departments  and  functions 
(marketing,  human  resources,  manufacturing,  finance,  etc.),  and  on  individual 
programmes  or  projects,  in  delivering  the  business  level  strategy. 


Figure  3:  Partington's  Three  Levels  of  Strategy  [Partington  2000] 


This  idea  was  presented  by  Robert  Fulmer  through  American  Management  Associates  in  1 978  and  can  be 
found  in  an  article  by  J.M.  Beggs  and  M.S.  Lane  [Beggs  1989], 
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These  and  other  similar  treatments  (such  as  TOGAF’s  human  actors)  speak  to  the  person  who  has 
a  goal — that  is,  the  goal-subject — and  alignment  of  goals  across  goal-subjects. 

For  the  same  reasons  we  don’t  need  a  taxonomy  of  goals,  goals  with  multiple  goal-subjects  are 
not  detrimental  to  goal  elicitation.  But  the  realization  that  goals  have  subjects  should  lead  us  to 
ask  for  them  when  we  elicit  business  goals — and  not  be  surprised  when  more  than  one  goal- 
subject  per  goal  is  revealed. 

One  way  to  classify  goal-subjects  is  by  the  organization  to  which  they  belong.  Multiple 
organizations  are  involved  in  the  construction  of  modern  systems.  The  customer,  acquirer,  and 
developer  organizations  are  the  norm,  but  each  of  these  may  interact  with  still  other  organizations. 
The  developing  organization,  for  example,  may  subcontract  a  portion  of  the  development;  it  may 
be  that  a  portion  of  the  development  is  a  modification  of  an  open  source  system,  in  which  case  the 
developers  of  the  open  source  portion  of  the  system  being  developed  become  stakeholders.  The 
system  being  acquired  may  need  to  interoperate  with  other  existing  systems  or  other  systems 
being  constructed,  and  stakeholders  of  those  systems  constitute  potential  goal-subjects. 

In  some  cases,  the  goal-subject  for  a  goal  may  be  an  organization,  as  opposed  to  specific 
individuals.  This  is  often  manifested  through  anonymously  written  documents  produced  by  that 
organization. 

2.4  The  Goal-Object  of  Business  Goals 

Here  we  introduce  the  concept  of  a  goal’s  object  (in  the  sense  of  a  verb’s  object  in  a  sentence). 

Instead  of  simply  asking  “What  are  your  business  goals?”  we  can  ask:  “What  do  you  wish  to  be 
true  for  or  about  X  as  a  result  of  developing  or  acquiring  this  system?”  The  placeholder  X  is  the 
goal’s  object,  the  entity  to  which  the  goal  applies. 

All  goals  have  goal-objects — we  want  something  to  be  true  about  something  (or  someone)  that  (or 
whom)  we  care  about.  For  example,  for  goals  we  would  characterize  as  furthering  one’s  self- 
interest,  the  goal-object  can  be  “myself  or  my  family.”  For  goals  we  would  characterize  as 
ethical,  the  goal-object  can  be  “the  social  or  natural  environment.”  For  some  goals  the  goal- 
object  is  clearly  the  development  organization,  but  for  some  goals  the  goal-object  can  be  more 
refined,  such  as  the  rank-and-file  employees  of  the  organization  or  the  shareholders  of  the 
organization.  For  DoD  acquirers,  we  often  hear  concern  voiced  for  “the  warfighter,”  another  kind 
of  goal-object. 

Some  goals  may  have  more  than  one  goal-object.  For  example,  consider  Fulmer’s  “Maximize 
profits  over  the  short  run.”  Here,  the  goal-object  can  obviously  be  the  developing  organization. 
But  it  might  also  be  “myself’  if  that  organization  has  profit  sharing.  Capitalists  in  the  Ayn  Rand 
school  would  certainly  argue  that  society  at  large  is  a  valid  goal-object  for  this  goal.4 

Goals  with  multiple  goal-objects  are  not  harmful  to  the  process  of  eliciting  business  goals. 


See,  for  example,  M.  Friedman,  “The  Social  Responsibility  of  Business  Is  to  Increase  Its  Profits,”  New  York 
Times,  September  13,  1970:  122-126. 
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Table  2  below  lists  all  of  the  business  goals  identified  in  the  Appendix  clustered  by  the  goal- 
object  for  which  the  goals  seem  primarily  aimed.  It  is,  in  other  words,  a  representative  cross- 
section  of  goal-objects  based  on  a  thorough  literature  search. 

Goal-objects  in  Table  2  start  small,  where  the  goal-object  is  a  single  individual,  and  incrementally 
grow  to  society  at  large.5 


Table  2:  Business  Goals  and  Their  Goal-Objects 


Goal-object 

Corresponding  business  goals 

Remarks 

Individual 

Personal  wealth,  power,  honor/face/reputation,  game  and  gambling  spirit, 
maintain  or  improve  reputation  (personal),  family  interests 

The  individual  who  has  these  goals 
has  them  for  him/herself  or  his/her 
family. 

System 

Managed  flexibility,  distributed  development,  portability,  open 
systems/standards,  testability,  product  lines,  integrability,  interoperability,  ease  of 
installation  and  ease  of  repair,  flexibility/configurability,  performance, 
reliability/availability,  ease  of  use,  security,  safety,  scalability/extendability, 
functionality,  system  constraints,  internationalization,  distributed  development, 
reduced  time  to  market 

These  can  be  goals  for  a  system  being 
developed  or  acquired.  The  list 
applies  to  systems  in  general,  but  the 
quantification  of  anyone  item  likely 
applies  to  a  single  system  being 
developed  or  acquired. 

Portfolio6 

Reduced  cost  of  development,  cost  leadership,  differentiation,  focusing,  reduced 
cost  of  retirement/moving  to  a  new  system,  retiring  systems,  smooth  transition  to 
follow-on  systems  and  replaced  legacy  systems,  replacement  of  labor  by 
automation,  diversification  of  operational  sequence,  elimination  of  intermediate 
stages,  automatic  tracking  of  business  events,  collection/communication/retrieval  of 
operational  knowledge,  improvement  of  decision  making,  coordination  across 
distance,  alignment  between  task  and  process,  management  on  basis  of  process 
measurements,  operate  effectively  within  competitive  environment,  operate 
effectively  within  technological  environment,  operate  effectively  within  customer 
environment. 

Artto  and  Dietrich  goals 

Creating  something  new,  provide  the  best  quality  products  and  services  possible, 
be  the  leading  innovator  in  the  industry 

These  goals  seem  to  live  on  the  cusp 
between  an  individual  system  and  the 
entire  organization.  They  apply  either 
to  a  single  system,  or  to  an 
organization's  entire  portfolio  that  the 
organization  is  building  or  acquiring  to 
achieve  organization-wide  goals. 

The  Arttro  and  Dietrich  goals  could 
apply  to  an  individual,  an 
organization’s  employees,  or  a  whole 
organization. 

Organization’s 

employees 

Provide  high  rewards  and  benefits  to  employees,  create  a  pleasant  and  friendly 
workplace,  have  satisfied  employees,  responsibility  toward  employees,  maintain 
jobs  of  workforce  on  legacy  systems 

Before  we  get  to  the  organization  as  a 
whole,  there  are  some  goals  aimed  at 
specifc  subsets  of  the  organization. 

Organization's 

shareholders 

Maximize  dividends  for  the  shareholders 

Organization 

Growth  of  the  business,  continuity  of  the  business,  this  year's  profits;  profits  ten 
years  from  now;  maximize  profits  over  the  short  run;  maximize  profits  over  the 
long  run,  survival  (of  the  organization),  maximize  the  company’s  net  assets  and 
reserves,  be  a  market  leader  in  your  respective  market(s),  maximize  the  market 
share,  expand  or  retain  market  share,  enter  new  markets,  maximize  the 
company's  rate  of  growth,  keep  tax  payments  to  a  minimum,  increase  sales 
growth,  maintain  or  improve  reputation  (of  the  organization),  achieve  business 
goals  through  financial  objectives,  run  a  stable  organization 

These  are  goals  for  the  organization 
as  a  whole.  The  organization  can  be  a 
development  or  acquisition 
organization,  although  most  were 
undoubtedly  created  with  the  former  in 
mind. 

Nation 

Patriotism,  national  pride 

Before  we  get  to  society  at  large,  this 
goal-object  is  specifically  limited  to  the 
goal  owner’s  own  country. 

There  were  no  business  goals  uncovered  in  our  search  whose  goal-subject  was  explicitly  the  larger,  non¬ 
human,  natural  environment. 

A  portfolio  is  “a  group  of  projects  that  are  conducted  under  the  sponsorship  or  management  of  a  particular 
organization”  [Archer  1 999]  or  “a  set  of  projects  that  are  managed  in  a  coordinated  way  to  deliver  benefits  that 
would  not  be  possible  if  the  projects  were  managed  independently”  [Platje  1994],  A  software  product  line  is  an 
example  of  a  portfolio  in  the  latter  sense  [Clements  and  Northrop  2002], 
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Society 

Run  an  ethical  organization;  respecting  ethical  norms,  responsibility  towards 

Some  interpret  “society”  as  “my 

society,  be  a  socially  responsible  company,  be  of  service  to  the  community, 

society,"  which  puts  this  category 

operate  effectively  within  social  environment,  staying  within  the  law,  operate 

closer  to  the  Nation  goal-object,  but 

effectively  within  legal  environment 

we  are  taking  a  broader  view. 

2.5  Summary  of  This  Section 

At  this  point  we  have  a  useful  classification  of  business  goals  that  we  can  set  forth  to  stimulate 
discussion  (“Do  you  care  about  meeting  financial  objectives?  What  about  meeting 
responsibilities  to  employees?”).  We  also  have  the  notions  of  a  goal’s  goal-subject  and  goal- 
object,7  which  will  likewise  stimulate  discussion  (“Who  are  your  stakeholders?  Who  or  what  is 
the  beneficiary  of  this  goal?”).  Together  these  give  us  the  skeleton  of  a  syntactic  structure  in 
which  to  express  business  goals  and  the  beginnings  of  a  stakeholder-based  process  to  elicit  them. 


Although  she  doesn’t  use  our  terms,  Anton  nicely  summarizes  what  we  mean  by  goal-subject  and  goal-object: 
“The  stakeholders  for  each  goal  are  determined  by  asking  who  or  what  claims  a  stake  in  this  goal  and  who  or 
what  stands  to  gain  or  lose  by  the  completion  or  prevention  of  this  goal”  [Anton  1998], 
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3  Expressing  Business  Goals 


Capturing  business  goals  and  then  expressing  them  in  a  standard  form  will  let  them  be  discussed, 
analyzed,  argued  over,  rejected,  improved,  reviewed — in  short,  all  of  the  same  activities  that 
result  from  capturing  any  kind  of  requirement.  This  section  discusses  how  to  capture  and  express 
business  goals  in  a  structured,  consistent  fashion.  We  begin  by  looking  at  two  areas  of  related 
work. 

3.1  Related  Work:  TOGAF  Business  Scenarios 

In  the  Appendix  we  discuss  how  business  goals  are  expressed  as  scenarios  under  the  guidance  of 
TOGAF.  Besides  giving  rich  guidance  on  how  to  gather,  analyze,  and  review  scenarios,  this 
framework  also  provides  a  very  complete  template  for  documenting  a  business  scenario  (Figure 
4).  While  TOGAF  contains  a  wealth  of  useful  information,  we  believe  architects  can  make  use  of 
a  lighter  weight  means  to  capture  a  business  goal. 
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PREFACE 

EXECUTIVE  SUMMARY 
DOCUMENT  ROADMAP 
BUSINESS  SCENARIO 
BUSINESS  SCENARIO  OVERVIEW 
BACKGROUND  OF  SCENARIO 
PURPOSE  OF  SCENARIO 
DEFINITIONS/DESCRIPTIONS  OF  TERMS  USED 
VIEWS  OF  ENVIRONMENTS  AND  PROCESSES 
BUSINESS  ENVIRONMENT 
Constituencies 
PROCESS  DESCRIPTIONS 
Process  “a” 
etc.  ... 

TECHNICAL  ENVIRONMENT 
Technical  environment  “a” 
etc.  ... 

ACTORS  AND  THEIR  ROLES  AND  RESPONSIBILITIES 
COMPUTER  ACTORS  AND  ROLES 
RELATIONSHIP  OF  COMPONENTS  AND  PROCESSES 
HUMAN  ACTORS  AND  ROLES 
RELATIONSHIP  OF  HUMANS  AND  PROCESSES 
INFORMATION  FLOW  ANALYSIS 
PRINCIPLES  AND  CONSTRAINTS 
IT  Principles 
Constraints 
REQUIREMENTS 
BUSINESS  SCENARIO  ANALYSIS 
PROBLEM  SUMMARY 
Issues 
Objectives 
SUMMARY 
APPENDIXES 

APPENDIX  A:  BUSINESS  SCENARIOS  -  ADDITIONAL  INFORMATION 
APPENDIX  B-n:  BUSINESS  SCENARIO  WORKSHOP  NOTES 


Figure  4:  TOGAF  Template  for  Documenting  a  Business  Scenario 

3.2  Related  Work:  Goal-Oriented  Requirements  Engineering 

Goal-oriented  requirements  engineering  emerged  in  the  late  1990s  as  a  way  to  derive 
requirements  from  overarching  goals  that  stakeholders  have  for  a  system.  It  was  a  recognition 
that  requirements  seldom  spring  fully  formed  out  of  the  minds  of  stakeholders,  but  are  the  result 
of  refinement  and  elaboration  of  goals  that  stakeholders  have  to  begin  with.  Under  this  view,  a 
particular  set  of  requirements  is  a  way  (possibly  not  the  only  way)  to  achieve  the  goals  of  the 
stakeholders. 
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For  example,  a  requirement  may  call  for  a  0.7-second  response  time  for  a  user  interaction.  But 
the  goal  behind  this  requirement  is  to  keep  users  from  becoming  frustrated  with  the  interactive 
system.  Knowing  only  the  requirement,  we  might  think  that  a  0.78-second  response  time  would 
be  unacceptable;  knowing  the  goal  lets  us  understand  that  0.78  seconds  may  well  be  just  fine. 

Capturing  the  goals  behind  requirements  helps  to  relate  requirements  to  the  organizational  and 
business  context,  clarify  requirements,  deal  with  conflicts,  drive  design,  capture  a  requirements 
rationale,  and  even  help  facilitate  requirements  reuse  [Yu  1998].  Capturing  goals  also  helps  in 
achieving  requirements  completion  and  avoiding  irrelevant  requirements  [van  Lamsweerde  2001]. 


Many  classification  schemes  exist  for  goals,  but  these  are  usually  based  on  the  semantics  of  the 
goal  itself.  A  typical  classification  scheme  uses  (or  looks  for)  keywords  such  as  “achieve,” 
“avoid,”  “maintain,”  “improve,”  “increase,”  “reduce,”  “make,”  and  so  forth,  or  words  that 
indicate  temporal  patterns  that  will  hold  (or  not  hold)  in  the  future  [van  Lamsweerde  2001].  A 
maintenance  goal  is  satisfied  as  long  as  its  target  condition  remains  true.  An  achievement  goal  is 
satisfied  when  its  target  condition  is  attained  [Anton  1997]. 


Dependencies  exist  among  goals.  A  goal  might  be  a  sub-goal  of  another,  or  be  completed  before 
another,  or  provide  information  to  another,  or  contractually  require  another,  and  so  forth.  Goals 
can  also  have  harmful  dependencies  or  “obstacles,”  such  as  when  one  goal  blocks  the 
achievement  of  another  [Anton  1997]. 


Figure  5  shows  a  template  for  capturing  a  goal  using  a  scenario. 


Goal: 

Type: 

Description: 

Name 

Name 

Text 

Action: 

Name 

Agent: 

Name(s) 

Stakeholders: 

Name(s) 

Constraints: 

Items 

Obstacles: 

Items 

Preconditions: 

Condition 

Postconditions: 

Condition 

Subgoals: 

Name(s) 

Figure  5:  Schema  for  Goals  [Anton  1997] 


3.3  Business  Goal  Scenarios 

Like  creators  of  TOGAF  and  some  segments  of  the  goal-oriented  requirements  engineering 
community,  we  choose  to  express  business  goals  using  scenarios.  The  purpose  of  a  business  goal 
scenario  is  to  ensure  that  all  business  goals  are  expressed  clearly,  in  a  consistent  fashion,  and 
contain  sufficient  information  to  enable  their  shared  understanding  by  relevant  stakeholders. 
Business  goal  scenarios  will  also  lend  themselves  to  processing  through  the  remaining  steps  of 
our  technique. 

We  have  chosen  a  scenario  template  based  on  the  previously  cited  work,  plus  Mitchell  and  Coles’ 
“who-what-why”  model  of  business  goals,  plus  our  own  experience  in  capturing  quality  attribute 
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requirements  with  scenarios  [Mitchell  2003,  Bass  2003].  Just  as  a  quality  attribute  scenario  adds 
precision  and  meaning  to  an  otherwise  vague  need  for,  say,  “modifiability,”  a  business  goal 
scenario  will  add  precision  and  meaning  to  a  desire  to  “meet  financial  objectives”  or  “increase 
market  share.” 

Our  business  goal  scenario  template  has  six  parts.  They  all  relate  to  the  system  under 
development,  the  identity  of  which  is  implicit.  The  parts  are  the  following: 

1.  Goal-subject.  This  is  the  stakeholder  who  owns  the  goal,  who  wishes  that  it  be  met.  The 
stakeholder  may  be  an  individual,  an  individual  in  an  identified  organization  if  more  than 
one  organization  is  in  play,  or  (in  the  case  of  a  goal  that  has  no  one  owner  and  has  been 
assimilated  into  an  organization)  the  organization  itself. 

2.  Goal-object.  This  is  the  entity  to  which  the  goal  applies.  A  goal-object  will  typically  be  one 
of  the  set  from  the  first  column  of  Table  2:  individual,  system,  portfolio,  and  so  on. 

3.  Environment.  This  is  the  context  for  this  goal.  For  example,  there  are  social,  legal, 
competitive,  customer,  and  technological  environments  [Osterwalder  2004],  Sometimes  the 
political  environment  is  key,  as  a  kind  of  social  factor.  If  upcoming  technology  is  a  major 
factor,  Bodde’s  2x2  matrix  can  be  used  to  express  its  potential  for  upsetting  the  current 
business  model  [Bodde  2007]. 

4.  Goal.  This  is  an  element  from  Table  1,  or  any  business  goal  (whether  in  the  table  or  not) 
that  the  person  being  interviewed  can  articulate.  One  way  to  express  the  goal  is  to  use 
Anton’s  precondition/postcondition  form. 

5.  Goal-measure.  This  is  a  measurement  for  determining  whether  the  goal  has  been  achieved. 
The  goal-measure  should  usually  include  a  time  component,  stating  the  time  by  which  the 
goal  should  be  achieved. 

6.  Pedigree  and  value.  The  pedigree  of  the  goal  tells  us  who  stated  the  goal,  the  degree  of 
confidence  the  person  who  stated  the  goal  has  in  it,  and  the  goal’s  volatility  and  value.  The 
value  of  a  goal  can  be  expressed  by  how  much  its  owner  is  willing  to  spend  to  achieve  it  or 
its  relative  importance  compared  to  other  goals.  Relative  importance  may  be  given  by  a 
ranking  from  1  (most  important)  to  n  (least  important),  or  by  assigning  each  goal  a  value  on 
a  fixed  scale  such  as  1  to  10  or  high-medium-low.  We  combine  value  and  pedigree  into  one 
part,  since  in  the  method  we  present  in  Section  4. 1  we  elicit  both  at  the  same  time.  It 
certainly  is  possible  to  treat  them  separately.  The  important  concern  is  that  both  are  captured. 

Elements  I  5  can  be  combined  into  a  sentence  that  reads 

For  the  system  being  developed,  <goal-subject>  desires  that  <goal-object>  benefit  from 
<goal>  in  the  context  of  <environment>  and  will  be  satisfied  if  <goal-measure>. 

The  sentence  can  be  augmented  by  the  goal’s  pedigree  and  value  (element  6).  Some  sample 
business  goal  scenarios  include 

•  For  MySys,  the  project  manager  has  the  goal  that  his  family’s  stock  in  the  company  will  rise 
by  5  percent  (as  a  result  of  the  success  of  MySys). 

•  For  MySys,  the  developing  organization’s  CEO  has  the  goal  that  MySys  will  make  it  50 
percent  less  likely  that  his  nation  will  be  attacked. 
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•  For  MySys,  the  portfolio  manager  has  the  goal  that  MySys  will  make  the  portfolio  30  percent 
more  profitable. 

In  many  contexts,  the  goals  of  different  stakeholders  may  conflict.  By  identifying  the  stakeholder 
who  owns  the  goal,  the  sources  of  conflicting  goals  can  be  identified. 

These  and  other  business  goals,  once  elicited  and  captured,  should  lead  to  asking  how  the 
architect  can  design  the  system  under  development  to  help  achieve  those  goals. 

3.4  A  General  Scenario  for  Business  Goals 

A  general  scenario  is  a  template  for  constructing  specific  or  “concrete”  scenarios  [Bass  2003].  It 
uses  the  generic  structure  of  a  scenario  to  supply  a  list  of  possible  values  for  each  non-boilerplate 
part  of  a  scenario. 

We  can  represent  a  general  scenario  for  business  goal  scenarios  using  a  table,  where  the  possible 
values  for  each  part  of  the  scenario  are  shown  in  the  columns  of  the  table.  Table  3  does  this  for 
business  goals.  Table  3  is  not  exhaustive,  but  it  can  aid  in  producing  exemplary  scenarios. 
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Table  3:  General  Scenario  Generation  Table  for  Business  Goals 


1.  Goal- 
subject 

...has  the 

goal 

that... 

2.  Goal-object 

...achieves. 

Any 

stakeholder 

or 

stakeholder 

group 

identified  as 
having 
legitimacy 
and  high 
salience 

Individual 

System 

Portfolio 

Organization's 

employees 

Organization’s 

shareholders 

Organization 

Nation 

Society 

4.Goal 


Maintaining  growth  and  continuity 
of  the  organization 

Meeting  financial  objectives 
Meeting  personal  objectives 

Meeting  responsibility  to 
employees 

Meeting  responsibility  to  society 
Meeting  responsibility  to  country 

Meeting  responsibility  to 
shareholders 

Managing  market  position 
Improving  Business  Processes 

Managing  quality  and  reputation 
of  products 

Managing  change  in 
environmental  factors 
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...in  the 
context  of... 


3.  Environment 


...and  will 
be  satisfied 
if... 


5.  Goal-measure 
(examples,  based 
on  goal  categories) 


7.  Pedigree:  Source, 
importance, 
volatility,  and  value 


Social 

(includes  political) 


Time  that  business 
remains  viable 


Value: 

1-/i 


Legal 

Competitive 

Customer 

Technological 


Financial 
performance  vs. 
objectives 

Promotion  or  raise 
achieved  in  period 


1-10 

H-M-L 

Resources  willing  to 
expend 


Employee 

satisfaction;  turnover 
rate 


Amount  given  to 
charity 

Contribution  to  trade 
deficit/surplus 

Stock  price, 
dividends 


Market  share 


Time  to  carry  out  a 
business  process 

Quality  measures  of 
products 

Technology-related 

problems 

Time  window  for 
achievement 


3.5  A  Document  Summarizing  Business  Goals 

A  document  summarizing  the  business  goals  would  be  helpful.  As  an  example,  Partington 
suggests  capturing  business  goals  in  a  business  requirements  definition  document  that  is  separate 
from  a  project’s  requirements  definition  [Partington  2000].  Figure  6  shows  the  contents  of 
Partington’s  business  requirements  definition. 

1.  Business  Requirements  Definition  (BRD) 

1.1. Business  aims 

1.2. Summary  project  description 

1.3. Indication  of  project’s  priority  within  business 

1.4.  Performance  requirements  (musts  and  wants) 

1.5.  Project  objectives  (cost,  time,  quality  and  relative  priorities) 

1.6.  Constraints 

1.7. Success  criteria  (quantify  measurable  business  aims) 

Figure  6:  Contents  of  a  Business  Requirements  Definition  [Partington  2000] 

Business  goal  scenarios  could  constitute  the  performance  requirements  and  project  objectives  in 
such  a  document. 

Flowever,  a  lighter  weight  approach  to  recording  this  information  could  be  appealing  to  many 
practitioners.  A  simple  spreadsheet  could  serve  well  in  many  cases. 
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4  From  Business  Goals  to  Quality  Attributes 


Our  goal  is  twofold.  First,  we  want  to  empower  architects  to  recognize  the  likelihood  of  missing 
requirements  by  giving  them  a  clear  and  full  picture  of  the  operative  business  goals.  Second,  we 
want  to  empower  architects  to  question  difficult  requirements  that  may  not  be  necessary  because 
they  do  not  support  any  important  business  goal. 

4.1  PALM 

Towards  these  two  ends,  we  have  developed  a  prototype  method  called  the  Pedigreed  Attribute 
eLicitation  Method  (PALM)  and  have  piloted  it  in  a  real-world  setting.  The  output  of  PALM  is  a 
prioritized  list  of  business  goals  and  the  associated  quality  attribute  requirements  that  derive  from 
the  stated  business  goals. 

The  steps  of  PALM,  which  can  be  carried  out  in  a  two-day  exercise,  are  listed  below.  For  each 
step  a  nominal  duration  is  given. 

1.  PALM  overview  presentation:  Overview  of  PALM,  the  problem  it  solves,  its  steps,  its 
expected  outcomes.  (30  minutes) 

2.  Business  drivers  presentation:  Briefing  of  business  drivers  by  project  management.  What 
are  the  overarching  business  goals  of  the  customer  organization  and  development 
organization  for  this  system?  (These  are  likely  to  be  broader  and  less  precise  than  the  goals 
elicited  and  refined  in  subsequent  steps.)  (60  minutes) 

3.  Architecture  drivers  presentation:  Briefing  by  the  architect  on  the  driving  (shaping)  business 
and  quality  attribute  requirements.  (30  minutes) 

4.  Business  goals  elicitation  exercise:  Using  the  standard  business  goal  categories  of  Table  1 
to  guide  discussion,  we  capture  the  important  business  goals  for  this  system.  Business  goals 
are  elaborated  and  expressed  as  business  goal  scenarios.  A  system  need  not  have  a  goal  or 
goals  from  every  row  of  Table  1,  but  Table  1  can  act  as  a  checklist  where  the  vacant  rows  are 
explicitly  (rather  than  implicitly)  excluded.  We  also  capture  the  effect  of  a  change  in  any  of 
the  environmental  factors  on  the  business  goal.  Participants  then  prioritize  the  resulting  set  to 
identify  the  most  important  goals.  Each  goal  derived  should  have  as  the  goal-object 
something  tied  to  the  system  under  development  (e.g.  individuals,  system,  or  portfolio).  That 
is,  goals  with  other  goal-objects  need  to  be  translated  into  goals  directly  tied  to  the  system 
under  development.  (2.0  hours) 

5.  Identifying  potential  quality  attributes  from  business  goals:  For  each  important  business 
goal  scenario,  participants  describe  a  quality  attribute  that  (if  architected  into  the  system) 
would  help  achieve  it.  If  the  quality  attribute  is  already  a  requirement,  this  is  recorded  as  a 
non-risk.  If  not,  it  is  recorded  as  a  risk.  For  each  business  goal  in  our  extracted  set,  we 
express  the  quality  attribute  requirements  that  would  allow  the  business  goal  to  be  satisfied, 
using  the  general  scenario  tables  of  Bass  to  suggest  specific  quality  attributes  [Bass  2003]. 
These  tables  embody  possible  quality  attribute  requirements  that  are,  by  definition,  at  either 
the  system  or  the  portfolio  level.  This  translation  process  will  be  straightforward  in  many 
cases,  since  goals  for  the  system  or  the  portfolio  are  often  expressed  in  quality  attribute  form 
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[Kazman  2005].  Architecturally  significant  requirements  can  be  tentatively  identified  in  this 
step.  (2.5  hours) 

6.  Examination  of  existing  quality  attribute  drivers:  For  each  architecture  driver  named  in  Step 
3,  we  identify  which  business  goal(s)  it  is  there  to  support.  If  it  supports  none,  or  if  any  of 
the  business  goals  it  supports  is  low  priority  or  has  a  pedigree  that  indicates  the  goal  is  of 
low  value  or  high  volatility  or  questionable  source,  that’s  recorded  as  a  risk.  Otherwise,  it’s 
recorded  as  a  non-risk.  In  that  case,  we  also  strengthen  the  quality  attribute  requirement  by 
asking  for  the  source  of  the  quantitative  part:  For  example,  why  is  there  a  40-ms 
performance  requirement  and  not  a  60-ms  performance  requirement?  (2.5  hours) 

7.  Exercise  conclusion:  Review  of  results,  next  steps,  and  participant  feedback.  (30  minutes) 

As  with  all  stakeholder-elicitation  methods,  PAFM  relies  on  having  the  key  stakeholders 
involved.  “Key”  stakeholders  are  ones  who  (according  to  the  criteria  of  Stakeholder  Theory) 
have  high  salience.  Their  involvement  can  vary  either  in  location  or  in  time.  If  all  of  the 
stakeholders  are  co-located  at  the  same  time,  the  PAFM  is  conducted  in  a  workshop  fashion.  If 
the  stakeholders  are  separated  in  time,  then  PAFM  is  conducted  in  an  interview  fashion.  In  our 
pilot,  we  conducted  PAFM  as  an  interview. 

Not  all  business  goals  can  be  achieved  through  quality  attributes  in  a  delivered  system.  However, 
architects  are  likely  to  be  able  to  support  business  goals  whose  goal-object  is  “system”  or 
“portfolio.”  The  farther  away  the  goal-object  is  from  “system,”  the  more  likely  the  associated 
goal  will  be  achieved  through  means  outside  an  architect’s  purview,  except  in  isolated 
circumstances.  Conversely,  it  seems  likely  that  business  goals  with  the  goal-object  of  either 
“system”  or  “portfolio”  are  ones  that  the  architect  can  most  affect;  these  are  the  types  of  goals  that 
are  directly  transferable  into  architectural  design  decisions.  In  Step  5  we  will  pay  special 
attention  to  business  goals  with  the  goal-object  of  “system”  or  “portfolio.”  We  can  scan  the 
business  goals  looking  for  words  like  “system,”  “portfolio,”  “product,”  “product  family,”  or 
proper  names  of  the  organization’s  products  or  portfolios.  We  will  also  look  for  business  goals 
that  can  easily  be  rewritten  so  that  the  goal-object  becomes  “system”  or  “portfolio.”  For 
instance,  a  business  goal  that  states  an  ambition  for  the  organization  to  possess  a  market-leading 
portfolio  has  “organization”  as  the  goal-object,  but  it  is  actually  expressing  an  ambition  for  its 
portfolio  and  can  be  rewritten  accordingly. 

4.2  Validating  the  Method 

We  held  a  workshop  in  Pittsburgh  and  one  in  Amsterdam  in  April  2009  to  help  us  validate  the 
approach  described  in  this  report.  We  invited  a  number  of  architecture  experts  to  the  workshops 
at  each  venue,  people  with  extensive  experience  in  designing  architectures  based  on  quality 
attribute  requirements.  At  these  workshops,  we  presented  the  elicitation  approach  and  took 
comments,  criticisms,  and  ideas  for  improvement.  We  also  conducted  a  mock  elicitation  exercise 
at  each  workshop  to  gain  preliminary  experience  with  the  practicalities  of  using  it  with  live 
subjects. 

The  Amsterdam  workshop  was  attended  by  contractors  and  Dutch  government  personnel  who 
were  on  the  development  and  ownership  sides,  respectively,  of  a  system  called  DigID.  DigID  is  a 
system  developed  for  the  Dutch  government.  It  provides  authentication  services  for  citizens  who 
wish  to  use  Dutch  government  web  services.  That  is,  a  citizen  will  log  into  the  website  of  a  Dutch 
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government  organization  to  perform  some  activity  (for  example,  pay  taxes).  The  website  will  use 
DigID  to  authenticate  the  citizen.  We  used  a  matrix  to  elicit  and  capture  the  business  goals  and 
associated  quality  attributes  for  DigID. 

A  sample  outcome  is  the  following.  Having  DigID  highly  available  supports  several  business 
goals: 

•  Maintaining  the  continuity  of  the  organization.  DigID  is  the  only  reason  the  organization  that 
owns  it  (government-based  organization)  exists.  If  the  other  branches  of  the  government  do 
not  use  DigID,  the  government-based  organization  (GBO)  will  cease  to  exist.  The  growth  and 
continuity  of  the  customers  that  depend  on  DigID  are  critically  important  to  the  GBO. 

•  Meeting  financial  objectives.  There  are  internal  (to  the  GBO)  availability  requirements.  If 
these  requirements  are  not  met,  funding  from  the  government  is  in  question. 

•  Maintaining  employee  satisfaction.  Employees  will  get  fewer  calls  (and  be  happier)  if  the 
system  is  highly  available. 

•  Improving  business  processes.  It  is  a  goal  of  the  tax  office  to  improve  its  business  processes, 
and  the  availability  of  DigID  is  an  essential  part  of  this  improvement. 

•  Managing  quality  and  reputation  of  products.  The  GBO  wants  DigID  to  be  seen  as  a  highly 
available  service  to  maintain  an  excellent  reputation  among  the  citizenry. 

This  exercise  validated  for  us  the  strong  link  between  business  goals  and  quality  attribute 
requirements.  The  participants  at  both  workshops  gave  us  strong  encouragement  as  to  the 
usefulness  of  establishing  a  business  goal-based  pedigree  for  quality  attribute  requirements  early 
in  the  life  cycle,  and  they  told  us  how  a  method  such  as  PALM  could  be  used  to  support  Request 
for  Proposal  (RFP)  activities  as  well  as  activities  to  respond  to  an  REP. 

4.3  Piloting  the  Method 

We  applied  PALM  to  a  system  being  developed  by  Boeing’s  Air  Traffic  Management  unit.  We 
will  call  this  system  The  System  Under  Consideration  (TSUC).  TSUC  will  provide  certain  on¬ 
line  services  to  the  airline  companies  to  help  improve  the  efficiency  of  their  fleets.  Thus,  there 
were  two  classes  of  stakeholders  for  TSUC:  Boeing  and  the  airline  companies.  The  stakeholders 
present  when  we  used  PALM  were  the  chief  architect  and  the  project  manager  for  TSUC. 

Step  2.  During  the  business  drivers  discussion  several  issues  surfaced  but  we  recorded  nothing 
officially.  One  important  element  of  this  discussion  was  the  identification  of  TSUC  as  an  element 
of  a  newly  planned  product  line. 

Step  3.  The  architectural  drivers  identified  during  Step  3  included  TSUC,  as  an  element  of  a 
product  line,  and  cost  and  schedule  for  delivery  of  TSUC.  Security  of  information,  usability  of 
TSUC  by  airline  personnel,  real-time  performance,  and  reliability  were  also  identified  as 
architectural. 

Step  4.  During  Step  4,  the  canonical  categories  of  business  goals  acted  as  triggers  for  detailed 
discussion.  The  discussion  of  goal  category  1  (“Maintaining  growth  and  continuity  of  the 
organization”)  overlapped  with  the  discussion  of  goal  category  2  (“Meeting  financial  objectives”). 


25  |  CMU/SEI-201 0-TN-01 8 


Goal  category  4  (“Meeting  objectives  toward  employees”)  triggered  a  discussion  of  how  TSUC 
would  affect  employees  in  the  business  unit  and  retention  of  software  engineering  personnel.  This 
discussion  also  covered  the  impact  of  TSUC  on  the  workload  of  airline  company  employees. 

Goal  category  5  (“Meeting  obligations  to  society”)  triggered  a  discussion  of  the  regulatory 
environment  in  which  airlines  operate  and  the  impact  of  this  environment  on  TSUC.  Furthermore, 
discussion  of  this  goal  led  to  a  discussion  of  the  future  changes  that  might  affect  air  traffic  and 
how  that  might  impact  TSUC. 

Goal  category  6  (“Meeting  responsibility  to  country”)  triggered  a  discussion  of  whether  TSUC 
could  be  used  by  the  U.S.  Department  of  Defense. 

Goal  category  8  (“Managing  market  position”)  triggered  a  discussion  of  time  to  market  and  how 
that  might  be  affected  by  architectural  decisions.  It  also  triggered  a  discussion  of  the  potential 
export  of  TSUC. 

Goal  category  9  (“Improving  business  processes”)  precipitated  a  discussion  of  governance  for 
TSUC  and  how  this  might  be  impacted  by  the  existence  of  the  product  line. 

Goal  category  1 0  (“Managing  quality  and  reputation  of  products”)  brought  about  a  discussion 
about  common  look,  feel,  and  usage  of  the  products  that  will  be  in  the  product  line. 

The  ten  canonical  business  goals  precipitated  discussions  that  were  wide  ranging.  All  participants 
agreed  that  important  issues  were  raised  that  were  unlikely  to  have  been  considered  in  the  goals’ 
absence.  Even  though  the  goal  categories  are  quite  abstract  and  unfocused,  they  were  successful 
in  triggering  discussions  that  were  relevant  to  TSUC.  The  result  of  each  of  these  discussions  was 
the  capture  of  a  specific  business  goal  relevant  to  TSUC. 

Step  5.  Adding  quality  attributes  to  the  discussion  generated  specific  scenarios  that  could  be 
useful  to  the  architect  designing  a  system.  For  example,  one  scenario  dealt  with  changes  in  the 
regulatory  environment  affecting  TSUC  and  the  airline  industry  and  how  these  changes  should 
affect  the  partitioning  of  functionality  in  TSUC. 

Step  6.  Here,  the  architectural  drivers  presented  in  Step  3  were  mapped  to  the  high-priority 
business  goals,  and  this  mapping  determined  that  all  of  TSUC’s  architectural  drivers  were 
motivated  by  identifiable  business  goals. 

It  must  be  said  that  this  was  a  lightweight  pilot — we  would  have  liked  more  stakeholders  to 
participate,  and  we  did  not  spend  time  prioritizing  the  business  goals  or  using  goal  priorities  in 
Step  5  or  Step  6.  Nevertheless,  we  feel  we  learned  what  it  is  like  to  apply  the  method  in  practice, 
and  after  the  exercise,  the  architect  and  the  project  manager  felt  that  the  results  were  valuable  and 
planned  to  present  them  to  the  Boeing  management  team  and  the  project  team,  respectively. 
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5  Conclusions 


We  believe  that  quality  attribute  requirements  drive  architectures,  and  that  business  goals  drive 
quality  attribute  requirements.  To  date,  quality  attributes  seem  to  have  received  the  bulk  of  the 
attention  in  this  “influence”  chain.  Our  work  has  attempted  to  do  for  business  goals  what  other 
work  in  software  architecture  has  done  for  quality  attributes:  treat  them  in  a  systematic, 
repeatable  fashion  that  is  borne  from  years  of  research  and  experience. 

We  have  created  a  “standard”  classification  scheme  for  business  goals  and  created  a  structured 
way  to  articulate  them  using  the  six-part  business  goal  scenario.  As  a  by-product  of  the  scenario 
format,  we  have  introduced  the  concepts  of  goal-subject,  goal-object,  and  pedigree.  We  have 
identified  the  major  forces  that  lead  to  business  goals  changing  over  time;  these  forces  can 
become  part  of  the  elicitation. 

We  have  created  a  facilitated  method,  PALM,  that  elicits  business  goals  and  establishes  the  link 
between  those  goals  and  the  quality  attribute  requirements  for  a  system  under  development. 

Where  such  a  link  cannot  be  established,  this  represents  a  risk  to  the  success  of  the  development. 
PALM  helps  an  architect  discover  missing  quality  attribute  requirements  early  and  empowers  the 
architect  to  question  the  necessity  of  overly  stringent  requirements  by  appealing  to  stakeholder- 
expressed  business  goals.  Along  the  way,  it  helps  to  increase  stakeholder  communication  and  buy- 
in,  and  to  put  stakeholders  on  the  same  page  with  respect  to  the  operative  business  goals. 

PALM  may  go  on  to  become  a  stand-alone  method  in  the  SEI  arsenal  of  architecture -centric 
practices,  or  its  important  parts  may  become  absorbed  into  the  Quality  Attribute  Workshop  or  the 
Architecture  Tradeoff  Analysis  Method,  which  both  currently  inquire  about  operative  business 
goals  in  a  less  structured  and  systematic  way. 
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Appendix  -  Survey  of  Literature  on  Business  Goals 


This  section  presents  a  survey  of  the  literature  on  business  goals.  Along  the  way  we  pick  up  some 
closely  related  work  in  marketing  strategies  and  business  models. 

Business  goals  are  the  system’s  raison  d'etre.  No  organization  builds  a  system  (or  commissions  a 
contractor  to  build  a  system)  on  a  whim;  rather,  it  wants  to  further  its  mission  and  ambitions. 
Common  business  goals  include  making  a  profit,  of  course,  but  most  organizations  have  many 
more  concerns  than  simply  profit. 

In  fact,  sometimes  profit  is  the  furthest  thing  from  an  organization’s  motives.  Acquisition 
organizations  such  as  the  U.S.  Department  of  Defense  have  acquisition  drivers,  primary  of  which 
is  to  acquire  a  system  that  can  meet  their  mission  goals.  Some  organizations  have  business  goals 
that  deal  with  meeting  an  organization’s  corporate  social  responsibilities.  These  are  “actions  that 
appear  to  further  some  social  good,  beyond  the  interest  of  the  firm  and  that  which  is  required  by 
law”  [Usunier  2008,  McWilliams  2001].  Corporate  social  responsibilities  can  include  economic, 
legal,  ethical,  and  philanthropic  responsibilities  [Carroll  1979,  1991].  Economic  responsibilities 
are  concerned  with  financial  performance  and  the  provision  of  goods  and  services;  legal 
responsibilities  are  concerned  with  compliance  with  societal  laws  and  regulations;  ethical 
responsibilities  relate  to  compliance  with  moral  codes  of  conduct;  and  philanthropic  (or 
discretionary)  responsibilities  relate  to  voluntary  involvement  and  support  of  wider  societal 
entities. 

A.1  Cross-National  Business  Goals 

Hofstede  and  colleagues  produced  a  set  of  15  dominant  business  goals  based  on  management 
literature  as  well  as  the  authors’  teaching  and  professional  experience  [Hofstede  2002].  Their  list 
of  goals  is  the  basis  for  many  other  authors’  investigations;  the  “Hofstede  goals”  are  widely 
referenced. 

Using  these  goals  as  the  basis  of  a  questionnaire,  Hofstede  and  colleagues  conducted  a  study  to 
determine  which  goals  were  most  important  in  15  countries  around  the  world.  They  surveyed 
junior  managers  and  professionals  taking  spare-time  MBA  classes,  collecting  responses  from 
1,814  respondents  composing  21  groups  at  16  universities  in  15  countries.  Importance  was  rated 
separately  for  each  goal  on  a  five -point  scale  from  “of  utmost  importance”  to  “of  very  little 
importance.”  They  asked  the  respondents  to  give  their  own  ratings  but  also  to  rate  the  importance 
of  each  goal  from  the  perspective  of  “the  typical  successful  business  person”  in  their  countries. 
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Table  2 

Mean  Rated  Importance  of  15  Business  Goals  across  21  Country/ 

University  Groups 

(standardized  data;  rank  1  =  most  important) 

For  Tycoon  For  Self 


Rank  Score  Rank  Score 


growth  of  the  business 

1 

1.26 

1 

1.00 

continuity  of  the  business 

2 

1.05 

2 

.86 

this  year's  profits 

3 

1.01 

9 

.26 

personal  wealth 

4 

.83 

10 

.08 

power 

5 

.68 

12 

-.62 

honor,  face,  reputation 

6 

.47 

7 

.48 

creating  something  new 

7 

.21 

6 

.49 

profits  10  years  from  now 

8 

.15 

5 

.56 

staying  within  the  law 

9 

-.12 

4 

.59 

responsibility  towards  employees 

10 

-.30 

3 

.64 

respecting  ethical  norms 

11 

-.52 

8 

.30| 

responsibility  towards  society 

12 

-.82 

11 

-.06 

game  and  gambling  spirit 

13 

-1.09 

14 

-1.57 

patriotism,  national  pride 

14 

-1.26 

13 

-1.28 

family  interests 

15 

-1.56 

15 

-1.73 

Figure  7:  Fifteen  Important  Business  Goals  [Hofstede  2002] 

Figure  7  shows  the  primary  results  statistically  combined  across  all  groups  and  countries. 
Although  the  point  of  the  paper  was  to  show  cross-national  differences  in  the  importance  of  these 
goals,  the  list  of  goals  is  all  we  need  for  our  purposes. 

A.2  Ethical  versus  Self-Interest  Goals 

Usunier,  Furrer,  and  Perrinjaquet  tried  to  determine  whether  business  executives  in  different 
countries  viewed  goals  rooted  in  self-interest  as  compatible  with,  neutral,  or  incompatible  with 
goals  based  on  “other”  interest,  such  as  following  ethical  mores  to  achieving  humanitarian  aims. 
They  concluded  that  “While  in  some  countries  ethics  and  self-interest  are  perceived  by  managers 
as  conflicting  goals,  in  many  countries  self-interested  and  ethical  goals  are  perceived  as 
independent...  [Also,]  differences  in  managerial  perceptions  of  goal  importance  and  compatibility 
can  be  explained  by  institutional  and  cultural  differences  rather  than  by  either  the  level  of 
economic  development  of  individual-level  variables  such  as  gender  and  work  experience” 
[Usunier  2008]. 

Usunier,  Furrer,  and  Perrinjaquet  took  their  list  of  goal  categories  from  the  Flofstede  study 
[Flofstede  2002]  but  divided  them  into  self-interest  goals  and  ethics-based  goals  shown  in 
Figure  8.  They  surveyed  1,742  respondents  from  executive  MBA  classes  in  15  countries.  Each 
respondent  was  asked  to  score  the  importance  of  each  of  these  goals  for  the  typical  successful 
businessperson  in  his  or  her  country.  Importance  was  rated  for  each  goal  on  a  five-point  scale. 
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Items 


Ethics 

Respecting  ethical  norms  (TETHI) 
Responsibility  towards  employees  (TEMPY) 
Responsibility  towards  society  (TSOC'I) 
Staying  within  the  law  (TLAWS) 

Self-Interest 

Growth  of  the  business  (TGROW) 

Personal  wealth  (TWELT) 

Power  (TPOWR) 

This  year’s  profits  (TPROF) 


Figure  8:  List  of  Business  Goals  Discriminated  by  Self-Interest  versus  "Other" -Interest  [Usunier  2008] 

A.3  Business  Goals  for  CEOs 

In  1978,  Robert  Fulmer  created  a  set  of  business  goals  for  an  American  Management  Institute 
study,  later  described  by  Beggs  [Beggs  1989].  Like  the  “Hofstede  goals,”  the  “Fulmer  goals”  also 
form  a  commonly  cited  set.  Other  researchers  have  used  them  to  study  chief  executive  officers 
[Lane  1987]  and  business  students  [Harpell  1986,  Beggs  1989].  Figure  9  shows  the  goals  as  used 
in  the  Beggs  study  of  business  students  and  their  perception  of  CEO  goals. 
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Goals 

Student 

mean 

raring 

s.d. 

Perceptions 
of  CEO 
mean  rating 

s.d. 

Student 

rank 

Perception 
of  CEO 
rank 

Mean  rating 

difference 

(CBO-srudent) 

/ 

value 

Maximize  profits  over  the  short  run 

2.82 

0.951 

2.75 

1.00 

20 

19 

-0.07 

-1.03 

Survival 

1.49 

0.805 

1.65 

0.983 

2 

2 

0.16 

2.42b 

Be  of  service  to  the  community 

Be  the  leading  innovator  in  the 

2.61 

03325 

2.85 

0.872 

19 

20 

0.23 

3.44* 

industry 

2.24 

0.917 

2.03 

0.855 

16 

9 

-0.21 

-3.14» 

Maximize  profits  over  the  long  run 

1.39 

0.848 

1.33 

0.880 

1 

i 

-0.06 

-087 

Be  a  socially  responsible  company 
Provide  high  rewards  and  benefits  to 

2.10 

0.865 

2.48 

0.933 

12 

15 

0.37 

4.90* 

employees 

Maximize  the  company's  net  assets  and 

2.21 

0.842 

2.54 

0.826 

14 

16 

0.31 

4.91‘ 

reserves 

Create  a  pleasant  and  friendly 

2.22 

0.793 

2.17 

0.917 

IS 

11 

-0.05 

-0.91 

workplace 

2.07 

0.928 

2.55 

0.885 

1 1 

17 

0.47 

6.67* 

Have  satisfied  employees 

1.81 

0.938 

2.19 

0.953 

4 

12 

0.36 

4.78* 

Keep  tax  payments  to  a  minimum 
Maximize  the  company's  rate  ot 

2.54 

0.944 

2.26 

0.976 

17 

13 

0.27 

3.71* 

growth 

2.00 

0.868 

1.94 

0.898 

9 

7 

-0.05 

-089 

Increase  sales  growth 

Provide  the  best  quality  products  and 

1.84 

0.833 

1.81 

0.812 

5 

3 

-0.03 

-0.49 

services  possible 

Be  a  market  leader  in  your  respective 

1.68 

0.893 

1.84 

0.930 

3 

4 

0.16 

2.03b 

market(s) 

Maximize  dividends  tor  the 

2.00 

0.892 

1.87 

0.855 

9 

5 

0.12 

-1.71* 

shareholders 

2.59 

0.945 

2.42 

0.970 

18 

14 

-0.16 

-2.37b 

Run  a  stable  organization 

1.97 

0.794 

2.04 

0.817 

6 

10 

0.06 

1.02 

Maximize  the  market  share 

1.98 

0.894 

1.90 

0.821 

7 

6 

-0.08 

- 1.2 4 

Run  an  ethical  organization 

Achieve  business  goals  through 

2.15 

0.891 

2.55 

03)58 

13 

18 

0.40 

5.76 b 

financial  objectives 

2.06 

0.815 

2.02 

0.909 

10 

8 

0.03 

0.49 

Figure  9:  Fulmer's  Business  Goals  [Beggs  1989] 

A.4  Marketing  Strategies 

Michael  Porter  has  written  a  panoply  of  books  on  competitive  strategy.  He  outlines  the  following 
marketing  strategies  for  corporations  [Porter  1998]: 

•  cost  leadership.  The  company  aims  at  providing  the  product  at  the  lowest  possible  cost. 

•  differentiation.  The  products  of  the  company  differ  by  a  certain  aspect  (e.g.,  service,  brand 
name,  etc.)  from  the  products  of  the  competition. 

•  focusing.  The  company  focuses  on  a  specific  niche  (providing  better  products/service  there). 

Also  identified  are  a  number  of  ways  in  which  IT  systems  can  bring  about  process  innovation. 
These  include 

•  replacement  of  labor  by  automation 

•  diversification  of  operational  sequence 

•  elimination  of  intermediate  stages 

•  automatic  tracking  of  business  events 
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•  collection,  communication,  and  retrieval  of  operational  knowledge 

•  improvement  of  decision  making 

•  coordination  across  distance 

•  alignment  between  task  and  process 

•  management  on  basis  of  process  measurements 

These  represent  business  goals  that  we  can  add  to  the  ones  offered  by  authors  cited  in  previous 
subsections. 

A.5  What  Drives  Business  Models 

De  Reuver,  Bouwman,  and  Maclnnes  conducted  a  study  of  how  a  start-up  organization’s  business 
models  change  over  time  and  the  factors  that  drive  that  change  [de  Reuver  2007].  Synthesizing 
definitions  from  other  authors,  they  say  that  a  business  model  is  “a  blueprint  for  the  way  a 
business  creates  and  captures  value  from  new  services  or  products”  [Chesbrough  2002].  A 
business  model  “describes  how  a  company  or  network  of  companies  aims  to  make  money  and 
create  consumer  value”  [Faber  2003];  it  is  “an  abstract  representation  of  how  organizations  create 
value  [Seddon  2003].  Thus,  business  models  seem  closely  related  to  business  goals. 

De  Reuver  and  colleagues’  objective  was  to  find  which  external  drivers  are  most  relevant 
throughout  the  phases  of  the  business  model  life  cycle.  They  concluded  that  technology  and 
market  drivers  are  most  relevant  during  initial  development  of  service  concept  and  underlying 
technology.  Regulatory  drivers  seemed  to  play  a  minor  role  through  the  life  cycle,  headline  cases 
like  Napster  notwithstanding.  Business  model  dynamics  seem  much  more  applicable  for  business 
models  centered  on  small,  start-up  companies  than  for  large,  established  businesses.  For  the  latter, 
the  role  of  these  drivers  appears  to  remain  steady  throughout  the  phases. 

The  conclusion  is  that  one  needs  to  focus  on  technology  and  market  forces  most  in  the  first  phase, 
especially  in  a  start-up.  Figure  10  summarizes  the  way  that  external  drivers  come  to  bear  on 
business  models  over  time. 

Chesbrough  provides  a  useful  and  readable  overview  of  business  models  and  their  use 
[Chesbrough  2007].  Seddon  and  Lewis  provide  a  similarly  helpful  overview  by  way  of 
distinguishing  the  concept  of  “business  model”  from  that  of  “strategy”  [Seddon  2003]. 

If  we  interpret  “value”  generally,  beyond  just  making  money,  then  business  models  can  exist  to 
serve  ethical  goals.  For  example,  Stubbs  and  Cocklin  write  about  and  present  examples  of 
business  models  where  environmental  and  social  sustainability  concepts  shape  the  driving  force  of 
the  firm  and  its  decisions  [Stubbs  2008],  and  their  paper  includes  references  to  other  work  in  this 
area. 
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Figure  1 0:  Drivers  of  Business  Model  Change  [de  Reuver  2007],  The  four  boxes  inside  each  instance 
of  the  business  model  denote  the  four  areas  a  business  model  must  address:  service , 
financial,  organization,  and  technology. 


A.6  An  Ontology  for  Business  Models 

Osterwalder  and  Pigneur  created  an  ontology  for  business  models  for  e-business  firms.  For  them, 
a  business  model  is  “nothing  else  than  a  description  of  the  value  a  company  offers  to  one  or 
several  segments  of  customers  and  the  architecture  of  the  firm  and  its  network  of  partners  for 
creating,  marketing,  and  delivering  this  value  and  relationship  capital,  in  order  to  generate 
profitable  and  sustainable  revenue  streams”  [Osterwalder  2004]. s  A  business  model  describes  the 
logic  of  a  “business  system”  for  creating  value  that  lies  behind  the  actual  processes  [Petrovic 
2001], 

After  an  extensive  literature  search,  Osterwalder  and  Pigneur  concluded  that  business  models  are 
constructed  around  products,  customers,  infrastructures,  and  financial  issues.  As  shown  in  Figure 
1 1 ,  they  interpret  business  models  as  the  conceptual  link  between  strategy,  business  organization, 
and  technology.  Because  there  is  often  quite  a  substantial  gap  in  understanding  between  these 
“worlds,”  a  business  model  can  serve  as  a  common  frame  of  reference  or  communication  vehicle. 
The  role  of  the  manager,  they  say,  is  to  adapt  a  company’s  business  model  to  external  forces,  such 
as  competition,  legal,  social,  or  technological  change  and  changes  in  customer  demand 
[Osterwalder  2004]. 


These  authors  apparently  consider  altruistic  aims  (such  as  Usunier's  “ethics”  goals)  to  be  invalid  parts  of  a 
business  model,  unless  those  aims  serve  “customers.”  That  seems  short  sighted,  especially  given  the  plethora 
of  literature  showing  that  organizations  focused  on  social  goals  outperform  those  fixated  on  profit  [Bernardez 
2005], 
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Figure  1 1:  Business  Models  Lie  at  the  Intersection  of  Strategy,  Organization,  and  Technology 
[Osterwalder  2004] 

Although  Figure  1 1  is  merely  the  prelude  for  Osterwalder  and  Pigneur’s  ontology,  we  can  use  it 
as  an  eight-way  classification  of  business  goals.  According  to  this  classification,  an  organization 
can  (and  should)  have  goals  to  control  or  adapt  to  each  of  the  five  environmental  factors  plus 
goals  to  manage  its  own  organization,  strategy,  and  technology.  For  example,  goals  to  manage 
the  environmental  factors  could  be  constructed  as  follows: 

1 .  operate  effectively  within  legal  environment 

2.  operate  effectively  within  social  environment 

3.  operate  effectively  within  competitive  environment 

4.  operate  effectively  within  technological  environment 

5.  operate  effectively  within  customer  environment 

Osterwalder  and  Pigneur  begin  their  ontology  by  naming  four  “pillars”  or  business  model 
“blocks”: 

1 .  The  product  innovation  block  describes  the  value  proposition  of  a  firm. 

2.  The  customer  relationship  block  describes  how  a  firm  gets  in  touch  with  its  customers  and 
the  kind  of  relationships  it  wants  to  establish  with  them. 

3.  The  infrastructure  management  block  describes  the  activities,  resources,  and  partners 
necessary  to  provide  the  first  two  blocks. 

4.  Th e  financial  aspects  block  describes  the  revenue  flows  and  the  pricing  mechanisms  of  a 
firm,  or,  in  other  words,  how  a  company  makes  money  through  the  other  three  blocks. 

Each  of  these  is  further  decomposed  into  constituent  elements  and  interrelationships.  For 
example,  one  element  of  the  product  innovation  block  is  the  value  proposition  for  a  product 
offering.  Figure  12  shows  the  associated  definitions  in  the  ontology.  Figure  13  shows  the 
definition  applied  to  a  fictional  credit  card  company. 
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VALUE  PROPOSITION 

A  VALUE  PROPOSITION  is  an  overall  view  of  a  firm’s  bundle  of  products  and  services  that 
together  represent  a  value  for  a  specific  CUSTOMER  SEGMENT. 

•  It  represents  value  for  TARGET  CUSTOMER(s). 

•  It  is  based  on  CAPABILITY(ies). 

It  is  composed  of  a  set  of  one  or  more  OFFERING(s). 

OFFERING 

An  elementary  OFFERING  describes  a  part  of  a  firm’s  bundle  of  products  and  services. 

•  It  has  a  DESCRIPTION. 

•  It  has  a  REASONING  {USE,  RISK  REDUCTION,  EFFORT  REDUCTION}. 

It  has  a  LIFE  CYCLE  {CREATION,  APPROPRIATION,  CONSUMPTION,  RENEWAL, 
TRANSFER}. 

•  It  has  a  VALUE  LEVEL  {ME-TOO,  INNOVATIVE  INNOVATION,  EXCELLENCE, 
INNOVATION}. 

»  It  has  a  PRICE  LEVEL  {FREE,  ECONOMY,  MARKET,  HIGH-END}. _ 


Figure  12:  The  Ontology  Definition  for  Value  Proposition  and  Offering  [Osterwalder  2004] 


Card  Builder 

Personalized  credit 

card 

Online  account 
management 

Description 

With  the  so-called 

Card  Builder 
customers  can  select 
their  own  individual 
combination  of 
interest  rate,  cashback 
rewards,  annual  fee 
and  servicing  options. 
They  build  their  own 
personalized  credit 
card 

The  easyMoney.com 
credit  card  is  accepted 
at  over  19.1  million 
locations  worldwide 
displaying  the 
MasterCard  logo  and  is 
financially  attractive. 

Customers  can  handle 
their  account  online 
and  receive  their 

statements 
electronically.  At 
every  moment  they 
have  an  up  to  date 
overview  of  their 
account  history. 

Reasoning 

A  customized  credit 
card  reduces  the 
financial  risk  of 
paying  for  options  the 
customer  doesn’t 
need  nor  use. 

By  configuring  his 
own  credit  card  the 
customer  benefits  from 
attractive  prices 
because  he  pays  for 
what  he  gets. 

Clients  can 
conveniently  manage 
their  accounts  from 
their  PC  and  profit 
from  lower  handling 
costs. 

Value  life  cycle 

Value  creation 

Value  Consumption 

Value  Consumption 

Value  level 

Innovation 

Innovation 

Innovation/me-too 

Price  level 

free 

economy 

free 

Figure  13:  An  Example  of  a  Value  Proposition  for  a  Firm's  Offerings 

A.7  Assessing  Technology  Risk 

The  previous  two  works  both  mention  technology  as  a  critical  environmental  factor  that  drives 
business  models.  Bodde  provides  a  simple  but  useful  framework  to  help  set  forth  that  factor;  the 
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framework  takes  the  form  of  a  2x2  matrix  [Bodde  2007].  The  top  row  lists  technologies  that  attack 
or  undermine  the  current  business  model — that  is,  these  technologies  pose  a  risk  to  business  as 
usual.  The  bottom  row  lists  technologies  that  reinforce  the  current  business  model.  The  left  column 
is  for  technologies  with  low  probability  of  performance  growth,  whereas  the  right  is  for  those  with 
significant  potential  for  growth.  Figure  14  shows  an  example  of  technologies  affecting  regulated 
power  (electrical)  utility  companies.  The  northeast  quadrant  represents  the  biggest  “threat” 
technologies — those  with  high  growth  potential  that  undermine  the  current  business  model. 


What. . .  me  worry? 

Paradise  Lost 

Attacked 

•  Rooftop  photovoltaics 

•  Fuel  cells 

•  Independent  power 

•  Digital  grid  control 

Prevailing 

producers 

•  IGCC 

Business 

The  Quiet  Life 

Paradise  Gained 

Model 

•  Large  scale  pulverized  coal 

•  Gas-cooled  nuclear  reactor 

Reinforced 

•  Light  water  reactor 

•  Sequestratio  of  C02 

•  Fuel  cells 

•  Digital  grid  control 

•  IGCC 

Low 

High 

Potential  for  Performance  Growth  of  the  Technology 

Figure  14:  Example  of  Matrix  to  Help  Determine  Technology  Risk  Factor  [Bodde  2007] 


A.8  Seven  Key  Elements  of  a  Business  Model 

Mitchell  and  Coles  provide  a  useful  framework  for  fleshing  out  a  business  model  based  on  the 
venerable  “who,  what,  when,  where,  why,  and  how”  model  (to  which  they  add  “how  much”) 
[Mitchell  2003]: 

1 .  “Who?”  defines  all  the  stakeholders  you  are  serving  or  affecting. 

2.  “What?”  describes  the  offerings  and  their  benefits  and  negative  influences  that  affect  each 
stakeholder. 

3.  “When?”  captures  the  timing  of  offerings’  effects  on  stakeholders. 

4.  “Where?”  identifies  the  location  for  delivering  benefits  and  other  impacts. 

5.  “Why?”  gives  the  rationale  for  providing  the  stakeholder  benefits  you  deliver. 

6.  “Flow?”  explains  your  method  of  providing  your  offerings  and  being  compensated  for  them. 

7.  “Flow  much?”  states  the  price  customers  pay  and  the  costs  they  incur. 

This  simple  framework  can  help  us  ask  stakeholders  the  right  questions  to  elicit  an  organization’s 
business  goals. 
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A.9  Stakeholder  Theory 


A  field  of  research  in  the  business/management  world  called  “stakeholder  theory”  views 
organizations  (e.g.,  corporations)  as  a  collection  of  stakeholders  all  working  out  their  stakes  with 
each  other.  Donaldson  and  Preston  compare  the  traditional  “input-output”  model  of  a  corporation 
with  a  stakeholder-centric  view  [Donaldson  1995]. 

Under  the  input-output  model  (Figure  15),  investors,  employees,  and  suppliers  are  depicted  as 
contributing  inputs,  which  the  “black  box”  of  the  firm  transforms  into  outputs  for  the  benefit  of 
customers.  (Of  course,  each  contributor  of  inputs  expects  to  receive  appropriate  compensation.)9 

Contrasting  Models  of  the  Corporation:  Input-Output  Model 


Figure  15:  Input-Output  Model  of  a  Corporation  [Donaldson  1995] 

In  the  stakeholder  model  (Figure  16),  all  persons  or  groups  with  legitimate  interests  who 
participate  in  an  enterprise  do  so  to  obtain  benefits,  and  there  is  no  prima  facie  priority  of  one  set 
of  interests  and  benefits  over  another.  Hence,  the  input-output  arrows  between  the  firm  and  its 
stakeholder  constituents  mn  in  both  directions. 


Donaldson  and  Preston  add  an  aside  that  is  eerily  prescient  given  the  dire  economic  conditions  at  the  time  of 
this  report:  “There  is,  of  course,  a  Marxist-capitalist  version  of  this  model  in  which  both  the  customer  and  the 
investor  arrows  are  reversed,  and  the  object  of  the  game  is  merely  to  produce  benefits  for  the  investors.  This 
interpretation  now  seems  to  be  confined  almost  exclusively  to  the  field  of  finance.” 
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Contrasting  Models  oi  the  Corporation:  The  Stakeholder  Model 


Figure  16:  Stakeholder  Model  of  a  Corporation  [Donaldson  1995] 

A  stakeholder  is  broadly  viewed  as  “any  group  or  individual  who  can  affect  or  is  affected  by  the 
achievement  of  the  organization's  objectives”  [Freeman  1984].  Narrower  definitions  exist, 
however,  that  focus  on  stakeholders  of  the  greatest  importance. 

Mitchell,  Agle,  and  Wood  do  a  thorough  job  of  summarizing  the  field  and  laying  out  the 
foundations  of  a  stakeholder  theory  [Mitchell  1997].  They  posit  that  stakeholders  have 
identifications  and  salience  (importance).  Stakeholders  can  be  people,  groups,  neighborhoods, 
communities,  even  the  natural  environment.  (Donaldson  and  Preston  point  out  that  under  non¬ 
discrimination  laws,  even  unsuccessful  job  applicants  can  be  stakeholders  in  a  corporation.)  A 
stakeholder’s  salience  comes  from  its  power,  urgency,  and  legitimacy.  Managers  are  the  only 
stakeholders  who  have  the  ability  to  assign  salience  to  the  other  stakeholders.  Stakeholders  can  be 
latent,  dormant,  discretionary,  demanding,  expectant,  dominant,  dependent,  dangerous,  and 
definitive,  where  each  of  these  is  technically  defined.  Figure  17  summarizes  the  most  important 
concepts  and  terms. 
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Key  Constructs  in  the  Theory  of  Stakeholder  Identification  and  Salience 


Construct  Definition 


Sources 


Stakeholder 


Power 


Bases 


Legitimacy 


Bases 


Urgency 


Any  group  or  individual  who  can  affect  or  is 
affected  by  the  achievement  of  the 
organization's  objectives 
A  relationship  among  social  actors  in  which 
one  social  actor,  A,  can  get  another  social 
actor,  B,  to  do  something  that  B  would  not 
have  otherwise  done 
Coercive — force/threat 
Utilitarian — material/incentives 
Normative — symbolic  influences 
A  generalized  perception  or  assumption  that 
the  actions  of  an  entity  are  desirable, 
proper,  or  appropriate  within  some  socially 
constructed  system  of  norms,  values,  beliefs, 
definitions 
Individual 
Organizational 
Societal 

The  degree  to  which  stakeholder  claims  call 
for  immediate  attention 


Bases  Time  sensitivity — the  degree  to  which 

managerial  delay  in  attending  to  the 
claim  or  relationship  is  unacceptable  to 
the  stakeholder 

Criticality — the  importance  of  the  claim  or 
the  relationship  to  the  stakeholder 

Salience  The  degree  to  which  managers  give  priority  to 

competing  stakeholder  claims 


Freeman,  1984;  Jones, 
1995;  Kreiner  & 
Bhambri,  1988 
Dahl,  1957;  Pfeffer,  1981; 
Weber,  1947 


Etzioni,  1964 


Suchman,  1995;  Weber, 
1947 


Wood,  1991 


Original — builds  on  the 
definition  from  the 
Merriam -Webster 
Dictionary 
Eyestone,  1978; 
Wartick  &  Mahon, 
1994 

Original — asset 
specificity  from 
Hill  &  Jones,  1992; 
Williamson,  1985 
Original — builds  on  the 
definition  from  the 
Merriam-Webster 
Dictionary 


Figure  1 7:  Key  Constructs  in  Mitchell  and  Colleagues’  Stakeholder  Theory  [Mitchell  1997] 

Mitchell  and  colleagues  refer  to  their  theory  as  defining  the  “Principle  of  Who  and  What  Really 
Counts,”  a  phrase  of  earlier  provenance  [Freeman  1994].  Donaldson  and  Preston,  as  well  as 
Freeman,  argue  that  the  stakeholder  role  is  “managerial” — that  is,  it  imposes  obligations  and 
opportunities  on  management — and  recommend  “managerial  attitudes,  structures,  and  practices 
that,  taken  together,  constitute  a  stakeholder  management  philosophy”  [Donaldson  1995]. 

Stakeholder  theory  gives  us  another  way  to  view  business  goals  by  categorizing  them  according  to 
the  stakeholders  who  own  them. 

A.10  Changing  Business  Models  Can  Define  an  Industry 

In  2007  IBM  and  the  Economist  Intelligence  Unit  polled  252  executives  from  the  telecom 
industry  to  obtain  their  views  on  some  of  the  current  business  themes  in  the  industry  [McIntosh 
2007],  These  themes  included  future  sources  of  value,  customer  service,  and  revenue  growth;  the 
role  and  significance  of  advertising;  the  “distinctive  capabilities”  of  the  telecom  provider; 
delivering  on  the  next-generation  network;  service  management  as  a  differentiator,  and  the  future 
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of  global  sourcing.  Forty  percent  of  the  respondents  were  drawn  from  Western  Europe,  30  percent 
from  North  America,  20  percent  from  Asia-Pacific,  and  10  percent  were  from  the  rest  of  the 
world. 

The  number  one  finding  of  the  2007  survey  is  that  the  source  of  value  perceived  as  primary  is 
business  model  transformation.  Business  model  transformation  handily  beat  out  such  old-school 
standbys  as  cost  reduction  and  revenue  growth.  Figure  18  summarizes  the  survey  results. 


Sources  of  value  in  global  telecommunications.  2002-2012. 


Source:  The  2007 IBM  Institute  for  Business  Value  and  Economist  Intelligence  Telecom  Industry  Executive  Survey  (n=252). 


Figure  18:  Summary  of  Telecom  Industry  Survey  Results  [McIntosh  2007] 


Five  years  ago,  only  34  percent  of  telecom  providers  singled  out  business  model  transformation  as 
a  source  of  value. 


While  many  business-school  authors  preach  business  model  agility  as  the  key  to  a  firm’s  survival 
and  success,  here  is  a  concrete  example  where  changing  business  models  represent  an  industry¬ 
wide  reality.  For  us,  this  is  relevant  because  if  we  are  going  to  ask  an  architect  to  be  sensitive  to 
his  or  her  organization’s  business  model,  we  must  also  ask  the  architect  to  be  prepared  to  respond 
to  a  fundamental  change  in  that  business  model. 


A.11  Business  Goals  Collected  from  Architecture  Evaluations 

In  a  software  architecture  evaluation  using  the  SEI  Architecture  Tradeoff  Analysis  Method 
(AT AM)  [Clements  2003],  one  of  the  steps  is  for  the  system’s  customer  or  the  development 
organization’s  project  manager  to  describe  the  business  goals  that  are  driving  the  acquisition  or 
development  of  the  system.  In  a  study  of  the  results  of  dozens  of  such  evaluations  using  the 
ATAM,  Kazman  and  Bass  summarized  and  categorized  the  business  goals  that  emerged  [Kazman 
2005].  The  categories  they  identified  are  shown  in  Table  4. 
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Table  4:  Business  Goal  Categories  from  Bass  and  Kazman  [Kazman  2005] 


Category 

Sample  goals 

Reduce  Total  Cost  of  Ownership.  This  category  includes 
business  goals  of  reducing  overall  cost  or  reducing  the  cost 
of  specific  parts  of  the  life  cycle,  such  as  development, 
deployment,  maintenance,  and  retirement. 

Reduce  Cost  of 
Development 

Manage  flexibility,  distributed 
development,  portability,  open 
systems/standards,  testability, 
product  lines,  integrability, 
interoperability 

Reduce  Cost  of 
Deployment 
and  Operations 

Ease  of  installation  and  ease  of 
repair 

Reduce  Cost  of 
Maintenance 

Flexibility/configurability 

Reduce  Cost  of 
Retirement  or 
Moving  to  a 

New  System 

Retiring  systems,  smooth 
transition  to  follow-on  systems, 
and  replace  legacy  systems 

Improve  Capability/Quality  of  System.  Business  goals  in 
this  category  refer  to  the  improvement  of  a  system  capability 
or  quality  compared  to  prior  versions  of  the  same  system  or 
contrasted  with  the  system(s)  being  replaced. 

Performance,  reliability/availability,  product  lines, 
ease  of  use,  security,  safety, 
scalability/extendibility,  functionality,  system 
constraints,  internationalization 

Improve  Confidence  in  and  Perception  of  the  System. 

This  category  includes  goals  intended  to  enhance  the 
reputation  of  the  developing  organization. 

Maintain  or  improve  reputation 

Support  Improved  Business  Processes.  This  category  of 
business  goals  is  concerned  with  improving  the  internal 
business  processes  and  the  structure  of  the  organization. 
Goals  here  include  supporting  distributed  development,  and 
maintaining  jobs  of  the  workforce  on  legacy  systems. 

Distributed  development,  maintain  jobs  of 
workforce  on  legacy  systems 

Improve  Market  Position.  Goals  in  this  category  have  to 
do  with  market  position  or  timing. 

Expand  or  retain  market  share,  maintain  or  improve 
reputation,  enter  new  markets,  reduce  time  to 
market 

This  grouping  is  based  on  field  observation  of  what  people  have  reported  to  be  the  business  goals 
of  systems.  The  categories  were  created  with  an  affinity  exercise  conducted  by  the  authors  after 
examining  the  raw  data.  There  are  obvious  relationships  and  overlaps  among  the  categories:  for 
example,  increasing  the  capability  or  quality  of  one’s  product(s)  is  a  good  way  to  increase  market 
share. 

Unlike  all  of  the  other  resources  in  this  section,  the  Kazman  and  Bass  goal  categories  are  the  only 
ones  drawn  purely  from  empirical  sampling.  Thus,  they  are  a  bit  scattered  across  the  map,  a 
function  of  uneven  elicitation  by  different  facilitators  during  ATAM  exercises.  The  first  three  are 
about  goals  directly  tied  to  the  system  being  developed,  whereas  the  goals  we’ve  seen  in  previous 
subsections  seem  more  organizational  in  nature.  This  dichotomy  is  glaring  in  the  Kazman  and 
Bass  goals,  and  non-existent  in  the  other  authors’  catalogs. 

A.12  Business  Goals  in  a  Multi-Project  (Portfolio)  Context 

Many,  if  not  most,  organizations  manage  a  multitude  of  related  projects  simultaneously.  Archer 
and  Ghasemzadeh  define  a  project  portfolio  as  “a  group  of  projects  that  are  conducted  under  the 
sponsorship  or  management  of  a  particular  organization”  [Archer  1999].  They  point  out  that  these 
projects  compete  for  scarce  resources.  The  goals  of  the  individual  projects  can  be  influenced  by 
each  other  and  by  the  goals  of  the  organization  at  large,  and  shrewd  organizations  manage  their 
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portfolios  as  well  as  their  projects.  Portfolio  management  is  “the  art  and  science  of  applying  a  set 
of  knowledge,  skills,  tools,  and  techniques  to  a  collection  of  projects  to  meet  or  exceed  the  needs 
and  expectations  of  an  organization’s  investment  strategy”  [Dye  1999]. 

Artto  and  Dietrich  provide  a  literature  summary  of  the  business  goals  (described  as  “dimensions 
of  project  success”)  of  portfolio-managing  organizations  [Artto  2007].  They  include 

•  Cooper,  Edgett,  and  Kleinschmidt,  1998 

maximizing  the  value  of  the  portfolio 
linking  the  portfolio  to  the  strategy 
balancing  the  portfolio 

•  Shenhar,  Levy,  and  Dvir,  1997 

project  efficiency 
impact  on  customer 
business  success 
preparing  for  the  future 

•  Saravirta  (2001)  and  Kotsalo-Mustonen  (1996) 

strategy  (e.g.,  new  competitive  advantage,  reference  value) 
relationship  (e.g.,  client  satisfaction) 
situation  (e.g.,  learning  by  doing,  unlearning) 
product/service  (e.g.,  commercial  success,  quality) 
project  implementation  (e.g.,  cost,  time,  process  quality) 

•  Morris  and  Hough  (1987)  and  Rouhiainen  (1997) 

technical  performance,  project  functionality,  client  satisfaction,  and  technical  and 
financial  performance  of  the  deliverable  for  the  sponsor/customer 
project  management:  on  budget,  on  schedule,  and  to  technical  specification 
supplier’s  commercial  performance:  commercial  benefit  for  the  project  service  providers 
the  learning  that  project  stakeholders  acquire 

A.13  Project  Types  Influence  Business  Goals 

Artto  and  Dietrich  present  the  argument  that  projects  of  different  types  will  have  different 
business  goals.  Project  types  differ  in  their  strategic  importance,  they  say,  and  each  type  typically 
requires  a  different  management  approach  [Artto  2007], 

Crawford,  Hobbs,  and  Turner,  as  well  as  Shenhar,  Levy,  and  Dvir,  and  Youker  conducted  studies 
of  project  classification  that  attempt  to  address  this  issue.  These  are  valuable  for  understanding 
not  only  different  project  types  and  their  characteristics  but  also  the  different  success  criteria  and 
their  strategic  importance  and,  accordingly,  different  successful  managerial  practices  associated 
with  each  project  type  [Crawford  2002,  Shenhar  2002,  Youker  1999]. 

Shenhar  and  colleagues  classify  projects  into  external  and  internal  types,  where  the  position  or 
closeness  of  the  customer  (external  or  internal)  provides  the  basis  for  the  classification.  This 
classification  also  considers  the  ultimate  customer  in  the  external  markets  in  relation  to  how  direct 
or  indirect  the  relationship  of  the  ultimate  customer  is  to  the  project  deliverable  [Shenhar  2002]. 
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Their  starting  point  is  innovation  management  literature  that  makes  a  distinction  between 
incremental  and  radical  innovation.  Thus,  according  to  Shenhar  and  colleagues,  projects  can  be 
either  strategic  or  operational  in  their  nature,  depending  on  the  project  type. 

External  projects  typically  relate  to  developing  products  for  customers  in  the  market.  Shenhar’ s 
study  distinguishes  among  external  projects  as  derivative,  platform,  and  breakthrough  projects 
[Shenhar  2002].  Wheelwright  and  Clark  call  these  three  project  types  commercial  development 
projects  [Wheelwright  1992].  Based  on  Shenhar  and  colleagues’  considerations,  derivative 
projects  relate  to  extending,  improving,  or  upgrading  existing  products.  They  typically  aim  at 
short-term  benefits,  and  they  are  thus  more  operational  than  strategic  in  their  nature.  Platform  and 
breakthrough  projects  relate  to  new  product  development  or  production  processes  where  there  is  a 
longer  term  perspective,  and,  accordingly,  more  striving  for  strategy. 

Another  interpretation  of  an  external  project  is  that  of  a  delivery  project  where  the  project  is  in  a 
commercial  setting  and  where  an  organization  is  running  projects  for  other  organizations  [Turner 
1999].  Such  external-delivery  projects  are  often  mere  production  or  manufacturing  devices  that 
run  more  or  less  predetermined  work  for  an  organization  according  to  a  contract  between  the 
customer  and  project  supplier  [Artto  2001].  The  similarity  of  project-based  operations  for  both 
external  and  internal  customers  is  demonstrated  by  Turner  and  Keegan,  who  defined  a  project- 
based  organization  as  a  stand-alone  entity  that  makes  products  for  external  customers,  or  a 
subsidiary  of  a  business  unit  of  a  larger  firm  that  makes  products  for  internal  or  external 
customers  [Turner  1999]. 

Shenhar  and  colleagues  divide  internal  projects  into  problem  solving,  utility,  maintenance,  and 
research  projects  [Shenhar  2002].  Wheelwright  and  Clark  distinguish  between  internal  projects 
based  on  research  and  development,  which  are  a  precursor  to  commercial  development,  and 
alliances  and  partnerships,  which  can  be  commercial  or  basic  research  directed  [Wheelwright 
1992].  Figure  19  describes  their  view  on  different  types  of  development  projects  (the  figure 
includes  four  types;  the  fifth  type — alliances  and  partnerships — can  include  any  of  the  other  four 
types).  Mikkelsen  and  colleagues  define  internal  projects  as  organizational  or  operational 
development  projects,  such  as  systems  planning  and  implementation,  the  introduction  of  new 
manufacturing  technology,  and  organizational  change  [Mikkelsen  1991].  Shenhar  and  colleagues’ 
utility  and  research  projects  usually  come  from  a  long-term  perspective  and  can  be  considered  as 
strategic  projects.  Problem-solving  and  maintenance  projects  usually  focus  on  the  shorter  term, 
typically  aim  at  performance  improvements,  and  can  be  seen  as  operational  projects  [Shenhar 
2002], 
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Figure  19:  Projects  Can  Be  Classified  by  How  Much  They  Change  Existing  Products  and  Processes 
[Wheelwright  1992,  Artto  2007] 


A.14  Enterprise  Architecture  and  TOGAF 

Enterprise  architecture  may  be  seen  as  establishing  a  processing  environment  in  which  an 
organization’s  business  goals  can  be  carried  out.  Therefore,  enterprise  architects  are  keenly 
interested  in  capturing  and  expressing  such  goals.  This  interest  is  captured  in  the  Architecture 
Development  Method  (ADM)  of  The  Open  Group  Architecture  Framework  (TOGAF)  [TOGAF 
2009], 

Part  III  of  the  TOGAF  ADM  includes  a  treatment  of  business  scenarios,  which  is  its  vehicle  for 
capturing  and  expressing  business  goals.  According  to  TOGAF,  “a  business  scenario  is 
essentially  a  complete  description  of  a  business  problem,  both  in  business  and  in  architectural 
terms,  which  enables  individual  requirements  to  be  viewed  in  relation  to  one  another  in  the 
context  of  the  overall  problem.” 

TOGAF’ s  purpose  for  capturing  business  goals  for  the  enterprise  architect  mirrors  our  own 
purpose  for  the  software  architect.  Without  such  a  purpose, 

•  “There  is  a  danger  of  the  architecture  being  based  on  an  incomplete  set  of  requirements  that 
do  not  add  up  to  a  whole  problem  description,  and  that  can  therefore  misguide  architecture 
work. 

•  “The  business  value  of  solving  the  problem  is  unclear. 

•  “The  relevance  of  potential  solutions  is  unclear. 
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TOGAF  also  touts  business  scenarios  as  way  to  increase  stakeholder  communication  and  buy-in. 
A  good  business  scenario  is 

•  Specific:  It  defines  what  needs  to  be  done  in  the  business. 

•  Measurable:  It  includes  clear  metrics  for  success. 

•  Actionable:  It  clearly  segments  the  problem  and  provides  the  basis  for  determining  elements 
and  plans  for  the  solution. 

•  Realistic:  The  problem  can  be  solved  within  the  bounds  of  physical  reality,  time,  and  cost 
constraints. 

•  Time-bound:  There  is  a  clear  statement  of  when  the  solution  opportunity  expires. 

These  criteria  are  abbreviated  as  “SMART.”  Creating  a  business  scenario  involves  the  following: 

1 .  identifying,  documenting,  and  ranking  the  problem  driving  the  scenario 

2.  identifying  the  business  and  technical  environment  of  the  scenario  and  documenting  it  in 
scenario  models 

3.  identifying  and  documenting  desired  objectives  (the  results  of  handling  the  problems 
successfully) 

4.  identifying  the  human  actors  and  their  place  in  the  business  model 

5.  identifying  computer  actors  and  their  place  in  the  technology  model 

6.  identifying  and  documenting  roles,  responsibilities,  and  measures  of  success  per  actor; 
documenting  the  required  scripts  per  actor,  and  the  results  of  handling  the  situation 

7.  checking  for  “fitness-for-purpose”  and  refining  only  if  necessary 

A.15  Summary  of  This  Section 

Table  5  shows  how  the  works  cited  in  this  section  helped  us  build  an  approach  to  eliciting  well- 
articulated  business  goals,  which  we  can  then  use  to  build  a  high-fidelity  list  of  quality  attribute 
requirements. 

Table  5:  Summary  of  Related  Work 


Related  work 

Summary 

How  it  helps  elicit 
business  goals 

Cross-national  business  goals 

The  “Hofstede  goals,”  a  widely  cited 
classification  of  business  goals 

Ethical  vs.  self-interest  goals 

Identified  a  set  of  “ethical”  and  “self-interest” 
business  goals 

Checklist:  Do  any  of  these 
business  goals  apply  to  your 
situation? 

Business  goals  for  CEOs 

The  “Fulmer  goals,”  a  widely  cited 
classification  of  business  goals 

Marketing  strategies 

Major  strategies  are  cost  leadership, 
differentiation,  and  focusing.  Also,  IT 
systems  can  be  about  process  innovation, 
such  as  replacement  of  labor  by  automation. 

Business  goals  collected  from 

Catalogued  and  categorized  the  business 
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architecture  evaluations 

goals  identified  in  dozens  of  ATAM-based 
engagements 

What  drives  business  models 

Technology,  market,  and  regulatory  drivers 
play  a  role  throughout  a  business  model’s  life 
cycle. 

How  do  these  drivers  affect  your 
business  goals  (especially  if  your 
organization  is  a  start-up)? 

An  ontology  for  business 
models 

Ontology  consists  of  four  “pillars”  (each  later 

elaborated  with  a  meta-model): 

1 .  Product  innovation  block  describes  the  value 
proposition  of  a  firm. 

2.  Customer  relationship  block  describes  how  a 
firm  gets  in  touch  with  its  customers  and  what 
kind  of  relationships  to  establish  with  them. 

3.  Infrastructure  management  block  describes 
what  activities,  resources,  and  partners  are 
necessary  to  provide  first  two  blocks. 

4.  Financial  aspects  block  describes  the  revenue 
flows  and  the  pricing  mechanisms  of  a  firm. 

How  do  these  pillars  affect  your 
business  goals? 

Managing  technical  risk 

2x2  matrix  to  help  reason  about  technology 
drivers  behind  business  goals 

Do  near-term  technologies 
reinforce  or  undermine  your 
business  goals? 

Seven  Key  Elements  of  a 
Business  Model 

Defined  questions  about  business  goals  in 
terms  of  who,  what,  when,  where,  why,  how, 
and  how  much 

Can  you  answer  these  questions 
for  your  business  goals? 

Stakeholder  theory 

Elaborates  on  the  “who”  of  Mitchell  and 

Coles 

Who  are  your  empowered 
stakeholders  and  what  are  their 
goals?  Begin  with  the 
stakeholders  listed  in  this  paper, 
and  then  add  your  own. 

Changing  business  models 
can  define  an  industry 

In  2007,  the  largest  perceived  source  of 
value  in  telecomm  was  changing  business 
models. 

How  is  your  business  model  likely 
to  change  over  the  foreseeable 
future? 

Goals  for  portfolios 

Projects  that  are  part  of  a  portfolio  tend  to 
have  business  goals  particular  to  the 
portfolio. 

Is  your  system  part  of  a  portfolio? 

Do  any  of  the  usual  portfolio- 
related  business  goals  apply? 

Project  type  influences 
business  goals 

Projects  can  be  external,  internal,  platform, 
breakthrough,  strategic,  and  so  on. 

Which  type  is  your  project?  Can 
we  use  that  to  elicit  business  goals 
based  on  its  type? 

TOGAF 

Capturing  business  goals  using  scenarios  for 
enterprise  architects 

What  are  the  actors,  the 
environment,  objectives,  success 
measures,  and  ranking  of  your 
business  goals? 
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